securityContext: runAsNonRoot and Capabilities
A securityContext decides who the process is and what it may do, and each setting has a characteristic failure. `runAsNonRoot` against a root image refuses to start at all; `readOnlyRootFilesystem` lets the container start and then breaks its first write; dropping capabilities produces `Operation not permitted` from a command that has always worked. All three are reproduced, with the exact wording.
Configuration and Security Guide 28 of 44 Intermediate
- Kubernetes1.36.4
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 17 min
- Reviewed23 August 2026
Written against the versions above. `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.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA1001 | 192.168.0.175 | Ubuntu 26.04 LTS | Control Plane Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE01 | 192.168.0.176 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE02 | 192.168.0.177 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE03 | 192.168.0.178 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
Before you start
- A cluster and kubectl.
- The session creates namespace
ckad-ctxand 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.
-
Who the process is by default
-
Refusing to run as root
-
Running as someone specific
-
A read-only root filesystem
-
Capabilities