Run Grails on HTTPS - grails

I want to run Grails on https on localhost. I have already configured HTTPS and can see the Apache page when localhost:443 is hit. Currently Grails runs on 8080. When I try running grails with grails -Dserver.port.https=443 run-app -https, I get Permission denied. I know this requires some kind of root access below port 1024. But when I try sudo grails run-app, this gives me command not found.
Any possible solutions?

Generally, it's a bad idea to run your web app as root. Practically speaking, your app becomes super exploitable. Any security flaw in your setup will suddenly give the attacker full root access to the server.
This is why it's more common to do one of the following:
Run a proxy such as apache or nginx or haproxy on port 443 with https, and grails on port 8080 without https. Set up the proxy to forward all requests to your grails app at 8080. Make sure the grails app only listens to localhost, so you can't go directly to yoursite.com:8080.
Run Grails at 8080, with https, only listening on localhost, and set up a netfilter/iptables rule to forward traffic on 443 to localhost 8080.
The two setups are essentialy the same. The main difference is whether to use a user level setup, or rely on an OS level service such as netfilters.

Related

Running containerized multiple applications using one ip address

I have a domain name https://example.com that points to a vps server on amazon lightsail. I have several applications i want to run. The apps are in vue js and some in spring and i am using nginx as the web server.
The landing page is basically an app running on port 3000 but using reverse proxy to display it at the root of example.com on port 80
I would like to run another app like:
example.com/one, example.com/two and example.com/three where one, two and three are applications each running inside a docker container.
How would i go about configuring my apps in this way keeping in mind the apps are running separately inside docker?
I highly suggest using Caddy for this type of setup.
Nginx is awesome and you could use that for the same purpose.
But for what you want to do caddy will work perfectly.
Just make sure to run each container on a different port.
Then use caddy as a reverse proxy to each container:
https://medium.com/bumps-from-a-little-front-end-programmer/caddy-reverse-proxy-tutorial-faa2ce22a9c6
Lets say you have containers running on port 5000,8800 and 9000
the you could do:
example.com
reverse_proxy /one localhost:5000
reverse_proxy /two localhost:8800
reverse_proxy /three localhost:9000
Caddy is cool because it will also setup SSL via Letsencrypt.
I didn't have time or a server to test this now, but let me know if it works.
God bless :)
Docker can only route to different ports. It can not determine the container by a http-path.
You need a reverse proxy (RP).
You have two options:
Install RP on host
You can install the RP on your host machine. There are many pros, like you can use the certbot for automatic lets encrypt certs. And you have the opportunity to use more docker-containers.
For this you have to publish ports in docker to your hostmachine.
Use your docker-nginx as RP
You can also set your frontend as RP. Just put your docker-containers in a docker-network and add the RP-config to your nginx.

Running an nginx forward proxy in kubernetes, getting connection timeout

I am trying to run a nginx forward proxy in kubernetes but I'm facing some issues.
My configuration:
nginx configured as forward proxy with http connect module, running on docker: Dockerfile - listens to 8888
K8S with istio 1.4 Deployment, service, gateway and virtual service configuration, host exposed to 36088
Firefox for testing
My steps:
For local testing, I'm configuring the connection settings in Firefox to point to the instance of nginx running in Docker on localhost:8888. With this configuration, the proxy is behaving as expected, denying and allowing traffic as per the nginx.conf.
For testing my pod in K8S, I can run kubectl port-forward name-of-my-pod 8888:8080 and configure Firefox to use the proxy forwarded on localhost:8080. As per point 1, the proxy works as expected and I can see the traffic hitting my pod in the logs.
Finally, To test my istio/AKS configuration, I can hit https://proxy.mydomain.net:36088 (defined in the gatwway) with a web browser. The url responds just fine and I can see the pod outputting some logs.
Sadly, though, when I configure Firefox to make use of proxy.mydomain.net:36088, I am getting connection timeout and I can see that the traffic is not actually hitting my pod and I am not getting any logs.
In other words, the proxy doesn't seem to be working when I use it as a proxy, but it responds fine when I access its URL a normal website.
Based on the fact that the traffic doesn't seem to hit my pod, I guess that I need to configure something else in istio/aks to ensure that my service/pod works as a proxy, but I don't know if my guess is right. Is anything obvious that am I missing?
After a lot of digging, we managed to make this work.
This is how our templates look like: deployment, gateway, service and virtualservice
The crucial point was:
Adding the .Values.istio.port.number to the istio-ingressgateway
configuring .Values.istio.port.protocol to TCP
configuring the gateway as PASSTHROUGH

Azure: container didn't respond to HTTP pings on port: 8080

I've suddenly started getting this error even though my app runs fine locally.
I'm running a rails app on Azure App Service.
I've tried setting an application setting PORT to 80 and my WEBSITES_PORT to 8080 with no luck.
puma.rb includes this
port ENV.fetch("PORT") { 3000 }
I've tried changing this to 8080 with no luck after deploying to Azure.
After looking online I'm really stuck as to why this is happening suddenly
Azure web application only support 80 and 443 port, but you could use WEBSITES_PORT point to other port. The variable "PORT" appears to be obsolete and may conflict with WEBSITES_PORT.
So my suggestion is deleting "PORT". Use WEBSITE_PORT directly to specify the desired port, such as 8080. By the way, the port must be the container exposes.

Docker container redirecting

Hi i have a url called :
https://wona.logs.co.za
And i need it to redirect to the speciic docker container at port 3000
( http://156.43.123.226:3000)
However when i try link https://wona.logs.co.za to 156.43.123.226:3000 i cannot enter a port number in the redirection to specify my docker container
Multiple things that do not fit.
you try to redirect https traffic to an http endpoint. That won't wortk
you are trying to directly redirect to another port (from 443, to 3000). That won't work either.
Solution
Create a proxy container. e.g. nginx that serves port 80 / 443 and redirects traffic to your application on port 3000. I recommend that you do not directly expose your application - only via the proxy.
Once you have a proxy container that listens to the same ports you can easily use the redirect as you described.
The question lacks the current setup of docker on mentioned server. From what i understood, is you already have docker running with orchestrator and a proxy server for main domain, and now you want to put up a subdomain which forwards traffic to one specific container.
For this, you need to spin an image of your application which listens on port 3000, add an entry in proxy server to forward traffic to your new container. Handle the ssl handshaking at proxy level.

Mochiweb Port 80

I am attempting to run BeepBeep through Mochiweb on Port 80. It works if I type sudo ./start_server.sh. Are there any security risks with running Mochiweb like this? If so how to remedy?
Thanks!
running any service as root has risk. It's hard to answer your question properly without more information though. Is this a production service or a dev instance you are running?
If production I would recommend running the mochiweb instance on a different port so it can run as a user and then using a proxy like nginx or apache to listen on 80 and forward the request.
You could start it on an unprivileged port and do port-forwarding in your firewall, so that port 80 goes to your unprivileged port.

Resources