Forbid running tenant containers as root

To simplify administration, Kubernetes containers share a user-ID namespace with the host by default. This means that UID 100 inside the container is identical to UID 100 on the host. The same is true for UID 0 (for example, the root user).

By default, containers start running as UID 0 (root). This poses several risks. For example, if an unauthorized user compromises the application, they could read and write files inside the container’s filesystem or gain remote access to it. If any host filesystems are mounted into the container, the attacker could read and write any files within them. Finally, if the container is run in privileged mode, the attacker unauthorized user could obtain host-level access. This could compromise not only the host itself, but also the control plane.

AWS recommends that each Dockerfile used to build a tenant’s container image specify a USER directive that is a non-root user name or ID. In addition, AWS recommends each tenant’s container be run with a specific user ID, group ID, and fsGroup (equal to the group ID) in the SecurityContext of a Kubernetes container specification.

Note

Pods that need to access Secrets or utilize IAM roles for service accounts, and that are not running as root, must specify an fsGroup in their securityContext that matches the group ID. This will prevent permission errors related to file ownership.

Admission controllers, discussed in Use admission controllers to enforce security policies, can help enforce these restrictions.