0

Running a container as root is a big "no" but are there times we really need to run privileged pods, or sometimes as root?

If so (and feel free to disagree), what are the mitigation controls we can employ?

There are some which I can think of:

  • For privileged pods, create an actual normal user (e.g. UID 1000) OR use "rootless" / fake root. Then, add Linux capabilities whenever required. Also a question: "Rootless" accounts are meant to trick applications that has a validation check on whether the running user is named "root" right?
  • For containers running directly as the real root, do controls even matter as the root can circumvent any other controls employed?
UndercoverDog
  • 612
  • 2
  • 17
transcend3nt
  • 39
  • 4
  • A container running as root would only inherit root level permissions within that container. Controls defined outside of the container, such as K8S network restrictions, would be just that, outside of the container. – Steven K7FAQ Aug 24 '22 at 17:25
  • Rootless containers just run as a user that does not have root level priv's. Here is a search result to help you dig deeper https://duckduckgo.com/?q=rootless+user+container&ia=web – Steven K7FAQ Aug 24 '22 at 17:27

2 Answers2

1

As a general rule, almost anything in a container that needs root can (and should) instead just get specific kernel privileges, and then drop them when no longer needed (e.g. ability to listen on reserved ports can be dropped once the listening socket is established). Some software probably does check for being named "root" (or, more likely, for being UID 0; it is only conventional that this used is named "root"), and in that case you may have no choice, but you can use a separate user namespace (as containers frequently do) such that processes running as this user don't have any special permissions outside the container.

With all that said: be aware that, in general, containers are NOT sandboxes. They can be used for sandboxing, but this is neither their main purpose (self-contained deployments, which generally won't trample the rest of the system but aren't designed to prevent code that is explicitly trying to break out the way a sandbox must be) nor the best tool for the job (which generally grants no access or privileges beyond what is explicitly added).

Of course, some software just can't practically be sandboxed, if e.g. its entire purposes is administrative (e.g. SSH server or remote management daemon). Sometimes such software even runs in containers (because, again, sandboxing is not the point, deployments are). In that case, you probably have no option but to run as root, without a separated user namespace, and with at least most kernel privileges enabled. On the other hand, the security model of such software already is "if the attacker compromises this, you're screwed, so here's some strong security controls to prevent that" whereas the security model of e.g. web apps is all too often "sales promised $BIG_CUSTOMER that they'll be able to access their uploaded docs with a fixed, permanent URL and no special authorization needed, and they won't budge on that" and at that point, good security is already out of the question and your goal is to keep it from becoming too much of a disaster, which ideally includes some sandboxing.

CBHacking
  • 40,303
  • 3
  • 74
  • 98
1

There's an important point to clarify here, which is the meaning of "privileged" as there's two ways it gets used.

  • The Docker flag "privileged" which is a short hand way of effectively removing any security isolation from the underlying host
  • A "privileged" container being one that runs as the root user inside the container.

In the first case this is commonly used by system software running in containerized environments. Often it would be possible to give the container specific rights instead of a blanket "privileged" level, however the developers have not gone to the effort of doing that. In some cases it's likely that the privileges required are effectively going to be root on the host anyway, so there's not much point in being fine-grained about it.

In the second case (running as root in the container) then we can make use of "rootless containers" to allow the process to think it's uid 0 inside the container whilst not effectively being uid 0 on the host. This however is not a pure win for security, as it can open up attack surface to an unprivileged container (e.g. the contained process has all capabilities inside its user namespace) which can increase the risk of Linux kernel vulnerabilities being exploited (there have been cases of this in kernel vulnerabilities this year)

Rory McCune
  • 60,923
  • 14
  • 136
  • 217