Is it a good practice to proxy web-applications from Docker containers?

Question

The current setup is the following:

• A production server (host) has only a few open ports, namely HTTP, HTTPS and secure ports for e-mailing.
• On the host there is a non-privileged user running a Docker engine and containers.
• Several web applications are running on Docker containers, each runs on a virtual bridged network provided by the Docker runtime. They have open ports HTTP and HTTPS. Applications are running on arbitrary web-server technology, like Apache 2.? or AKKA-HTTP.
• Only one "http-proxy" container exposes its ports (80, 443) to the host. On this container, a non-privileged user is running a mod-secured Apache 2 server which only forwards requests based on the domain requested and forwards to one of the application containers.
• Mail server is running on a Docker container with non-privileged user that exposes its ports to the host.

Questions are:

1. Are there any drawbacks to this model?
2. How would it be more secure?
3. How exposed are the application-containers to attacks?
4. Are there any security considerations regarding Docker?

Thanks!

Answer 1

Are there any drawbacks to this model?

I don't see any immediate drawbacks, except for the overheads and the use of disk space if you deploy your applications on a rolling basis without keeping volumes in check. Keep in mind that "A Docker data volume persists after a container is deleted. " see the Docker documentation.

However, there might be a few longer-term drawbacks. For example: since you run this in production, how often do you apply security updates to your containers? Given that docker images are a step removed from upstream, security patches might not be deployed fast enough. How often do you check for updates to your containers, and redeploy them?

Also, if one of your containers gets 0wned, do you filter outbound connections? What if a trivial exploit in your app makes it part of a botnet?

How would it be more secure?

It depends. Do you mount the host's /proc or /sys in any container? If so, beware of this kind of attacks (and search for 'docker escape' for an entertaining read)

How exposed are the application-containers to attacks?

For attacks coming from outside your network perimeter, they are as exposed as if the applications were running as regular UNIX processes on a system.

Oddily, for attacks coming from other containers you are actually increasing your attack surfaces: assuming some containers can see others (e.g. web server can see the db server, or a log server, and so on) you have to make sure each container does not run extra services and most importantly keep them up to date.

Are there any security considerations regarding Docker?

Yes but the question is too broad. There are docker escapes due to poor container management (e.g. mounting /proc). There are potential docker exploits. There is the occasional misconfiguration that allows local users to attack it. If you're looking for a silver bullet to deploy and forget, you'll be disappointed...

Answer 2

Running a lightweight proxy in front of a web/appserver is a good idea, and while I am a big fan of apache httpd, I think it is a poor choice as a proxy; it is far from lightweight so your architecture will not cope with high traffic volumes. I would recommend nginx or ATS or possibly varnish. But there isn't an ATS nor varnish port of modsecurity and the nginx version is not as stable as the apache module. There are alternative WAFs for all three - whether they are appropriate for you depends on what you are doing with your WAF.

As lorenzog says docker images tend to lag in releasing patches. You've not mentioned how you propose to address configuration, deployment and patching of the servers.

All your daemons should run as non-privileged users, and all the standard applications on linux distributions do run as a non-root user - but most daemons will start as root in order to grab a low numbered port. You can start it as non-root on a high numbered port and use iptables to do port translation or use linux capabilties to delegate permission to bind a low numbered port or do the port mapping elsewhere. But do beware that this may involve tinkering with config files which may lead to conflicts with the distribution patches.

Answer 3

Your setup sufficiently isolates the different environments so that a breach in one container does not give access to another container.

One thing you should check is that the web applications are not run as root within the docker containers. The web application code should be run as a normal user.