Security Contexts

​

Quick field reference

​

Examples

1. Pod-level securityContext (applies to all containers in the Pod)

apiVersion: v1
kind: Pod
metadata:
  name: secctx-pod
spec:
  # Pod-level securityContext applies to all containers unless overridden
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  - name: ubuntu
    image: ubuntu:20.04
    command: ["sleep", "3600"]

2. Container-level securityContext (overrides Pod-level runAsUser)

apiVersion: v1
kind: Pod
metadata:
  name: secctx-container-override
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
  containers:
  - name: ubuntu
    image: ubuntu:20.04
    command: ["sleep", "3600"]
    # This container-level securityContext overrides the Pod-level runAsUser
    securityContext:
      runAsUser: 2000
      runAsNonRoot: true

3. Adding Linux capabilities to a container

apiVersion: v1
kind: Pod
metadata:
  name: secctx-capabilities
spec:
  containers:
  - name: net-tools
    image: alpine:3.18
    command: ["sleep", "3600"]
    securityContext:
      capabilities:
        add: ["NET_ADMIN", "SYS_TIME"]
        drop: ["MKNOD"]

​

Best practices

• Always use numeric UIDs/GIDs for runAsUser, runAsGroup, and fsGroup in manifests.
• Prefer runAsNonRoot: true whenever your application is compatible — this prevents accidental UID 0 execution.
• Apply the least-privilege principle: only add capabilities that your workload truly requires and explicitly drop capabilities you do not need.
• Capabilities are applied per container; set them at the container level to avoid granting unnecessary privileges to other containers in the same Pod.
• Enforce cluster-wide security posture using PodSecurity admission, Gatekeeper, or another policy controller—these provide consistent rules across your cluster. See Pod Security Standards: https://kubernetes.io/docs/concepts/security/pod-security-standards/

​

Viewing and troubleshooting

• Inspect the resolved security context of a running Pod (full manifest):

kubectl get pod secctx-pod -o yaml

• See a human-readable summary and events:

kubectl describe pod secctx-pod

• If a Pod fails to start due to security validation, check the Pod events and admission controller logs (if configured).