securityContext: runAsNonRoot and Capabilities

Configuration and Security / Guide 28 of 44 / Intermediate

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

securityContext exists at two levels and they are not the same set of fields. Pod level takes runAsUser, runAsGroup, fsGroup and runAsNonRoot; container level takes those plus capabilities, readOnlyRootFilesystem, allowPrivilegeEscalation and privileged. fsGroup and capabilities are the two that are only available at one level each, and putting either in the wrong place is a silent no-op or a rejection.

This guide includes

Use this when a Pod has to run as something other than root and be able to prove it. This matters because securityContext exists at two levels with different fields, and every setting has a visible effect you can check rather than take on trust.

• confirming the default really is root, using id from inside the container
• setting runAsNonRoot: true against a root image and watching it refuse to start
• running as a specific uid, gid and supplemental group, and reading all three back
• mounting a read-only root filesystem and watching a write be refused
• dropping and adding capabilities, then reading CapEff to confirm what took effect

Before you start

• A cluster and kubectl.
• The session creates namespace ckad-ctx and five Pods: an unrestricted one, one that is refused, one running as a specific UID, one with a read-only root filesystem, and one with almost all capabilities dropped.

1. 1

   Who the process is by default

2. 2

   Refusing to run as root

3. 3

   Running as someone specific

4. 4

   A read-only root filesystem

5. 5

   Capabilities

Official sources

• Configure a Security Context for a Pod or Container
• Pod Security Standards
• Linux capabilities