0

In a Kubernetes environment, I suppose that the root user should not be allowed by default to mitigate the risk in case the host OS was accessed from inside a container. This setting should be done by writing in PodSecurityPolicy.

Considering this, I am just wondering: Why can we use the root user to run containers in public cloud Kubernetes services such as EKS, AKE and GKE? Do they have another layer of security measures to prevent containers from being compromised by attackers?

Stuggi
  • 3,366
  • 4
  • 17
  • 34
rks
  • 1
  • 1

2 Answers2

1

The root user is allowed to perform any action on a Linux system including running Docker containers. There is no way to not allow the root user to run docker containers. Instead the way to go is to limit the access to the root user and use sudo to allow non root users to perform certain actions on the system.

However in case of Docker it doesn't matter that much because:

The docker group grants privileges equivalent to the root user. For details on how this impacts security in your system, see Docker Daemon Attack Surface.

manage-docker-as-a-non-root-user

So any Linux user which has permission to execute docker commands can gain root privileges on the system.

Root privileges inside a container are not a problem as Docker is a OS-level virtualization technology. The root user inside the container doesn't have access to the underlying OS running the docker daemon.

Henrik Pingel
  • 8,676
  • 2
  • 24
  • 38
  • Sorry, my question above may not have been clear. I suppose, as the best practice, we should prevent running processes as root inside a container, and also escalation to root as described here. https://kubernetes.io/blog/2018/07/18/11-ways-not-to-get-hacked/#8-run-containers-as-a-non-root-user Considering this, why can we do these in public cloud Kubernetes services? – rks Dec 06 '20 at 02:02
  • sorry, I forgot to mention @Henrik Pingel – rks Dec 06 '20 at 23:26
  • Docker is a OS-level virtualization technology. The root user inside the container doesn't have access to the underlying OS running the docker daemon. – Henrik Pingel Dec 08 '20 at 17:28
  • 1
    It is usually the case. But, with a serious vulnerability either in Docker or the Linux kernel itself, one could get access to the host os from containers if they are running as root. – rks Dec 09 '20 at 02:04
1

Even if there is the possibility of a containerized process gaining access to the host OS due to an unfixed vulnerability, and thus having full control on the system due to it running as root, I believe public clouds choose not to enforce this by default because many well-known software packages have their main process run as root - for example, the nginx service relies on a main daemon process running as root, which in turn spawns the worker processes running as www-data for better security.

Arnau C.
  • 125
  • 5
  • @Armau C. Thank you for your reply. Yes, I understand that enforcing this best practice would be really frustrating for users. However, "a containerized process gaining access to the host OS" sounds a significant security issue and I am just wondering how public clouds can be sure this does not happen to them? I mean, if this happens, it would basically mean the complete loss of user's trust, right? – rks Dec 09 '20 at 02:00
  • @rks, yes, it would result in the container's process gaining control over the entire node, though to minimize the likelihood of this from happening, automatic upgrades for the Kubernetes master(s) and nodes may be enabled by default to have newly discovered security holes in Kubernetes patched in production clusters as soon as possible, as in: https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster#upgrade_your_infrastructure_in_a_timely_fashion_default_2019-11-11 – Arnau C. Dec 10 '20 at 15:01