Docker, running programs as Root and AWS

Question

It is well known that running programs inside your docker container as root is bad practice. As far as I can tell, the reason for this is because root on the container is rather similar to root on the host (eg the answer to this question), and escaping a container is well documented.

The particular infrastructure in question is an API service hosted in AWS in which the server application executes as the root user, as provided in the servers getting started guide. The only information available inside this container is the server application and access credentials to our DB - which the server application requires. While access to the access credentials is a risk the server application requires access to these credentials even if it ran as a regular user, and I can't see that running the server as root increases this risk.

My question boils down to:

• Given that this service is hosted on AWS and is ephemeral, how can I quantify the security risk caused by an external facing application running as root?

Answer 1

My question boils down to:

• Given that this service is hosted on AWS and is ephemeral...

Ashes to ashes, dust to dust; everything is ephemeral, just on different time scales.

If you are using the AWS server in production and it has access to your real production database, then it doesn't really matter too much that it is "ephemeral."

how can I quantify the security risk caused by an external facing application running as root?

There can be many different risks associated with "an external facing application running as root." To start with, you might want to think about some of the specific ways the server could fail, from a security perspective.

Once you have a list of failure modes (ways it can fail) to consider, you can try to quantify the risk, but the result will likely be "semi-quantitative" or "qualitative" at best. What you need to do is to try and quantify the two components of risk, likelihood and severity, for each failure mode. Often this is done by a team looking at specific failure modes and trying to reason about what would be the worst thing that could happen during the failure and how likely is the failure.

Answer 2

The risk of running root in a container is that breakout is easier (there have been multiple container breakout CVEs where being "UID 0" was a pre-requisite for exploitation).

If there is no information on the host that you're concerned about and access to the underlying host would provide no advantage to an attacker that they don't already have from exploiting the application running in the container, it's likely that there's limited additional security risk to running the container as root.

Of course that's not to say that there's not compliance concerns, as compliance often doesn't actually take account of security when saying something's bad :)

If you want to further analyse this to provide evidence to external parties that the risk has been considered I'd agree with @hft that threat modelling the application (asking what can go wrong) and documenting the likely attacks and (lack of) impact of container breakout would be a good approach.