securityContext and Non-Root Containers

Configuration and Secrets / Guide 37 of 103 / Intermediate

• Kubernetes1.36.4
• Cluster4 nodes
• Runtimecontainerd 2.2.6
• CNICalico v3.32.1
• TimeAbout 30 min

UID values are arbitrary choices. The enforcement behaviour is not.

This guide includes

Use this when a container should not be running as root - which it is, unless something says otherwise. This matters because several securityContext settings overlap, and knowing which one actually refused a write is the difference between fixing it and guessing at it.

• seeing that a container runs as root unless the image or the Pod spec says otherwise
• confirming the effective user from the container's own id output
• attempting a write outside the mounted volume and having it refused
• working out which setting did the refusing, rather than assuming which one

Before you start

• A working cluster and kubectl.
• The Pods guide. securityContext appears at two levels of a Pod spec and knowing the shape helps.
• An awareness that this is the Pod-level half of container security. Pod Security Admission enforces these settings cluster-wide and has its own guide.

1. 1

   The default is root, and that is the problem

2. 2

   Confirm who it is

3. 3

   Which setting actually blocked the write?

4. 4

   Clean up

Official sources

• Configure a security context for a pod or container
• Pod Security Standards
• Pod Security Admission
• Seccomp for a container