Skip to main content
When you run a Docker container you control several security-related settings — for example, the user ID that runs the process inside the container and the Linux capabilities granted to it. Kubernetes provides equivalent controls through security contexts, which let you express those settings declaratively for Pods and containers. In Kubernetes, containers are grouped inside Pods. You can set security controls either at the Pod level or at the container level:
  • Pod-level security settings live under spec.securityContext (commonly called the pod security context). Fields such as runAsUser, fsGroup, and seLinuxOptions set defaults that apply to every container in the Pod unless a container explicitly overrides them.
  • Container-level security settings belong under each container’s securityContext (spec.containers[*].securityContext). Container-level settings take precedence and override equivalent Pod-level defaults.
If you set the same field in both places, the container-level value wins:
A slide titled "Kubernetes Security" showing a circular diagram with user icons and two rectangular labels/buttons both reading "MAC_ADMIN," suggesting user/role representation.
Pod-level example — set a default user for all containers in the Pod:
In this example, every container in the Pod will run as UID 1000 unless a container provides its own securityContext that overrides runAsUser. Use kubectl apply -f to create the Pod, and inspect the applied values with:
  • kubectl get pod web-pod -o yaml
  • kubectl describe pod web-pod
Container-level example — set a specific user and add Linux capabilities (container overrides):
The capabilities field modifies the set of Linux capabilities for the container. Note that Linux capabilities must be configured at the container level (containers[*].securityContext) — they are not supported in the Pod-level spec.securityContext. Notes:
Pod-level securityContext supports fields such as runAsUser, fsGroup, and seLinuxOptions. Linux capabilities (the capabilities field) must be configured at the container level under containers[*].securityContext.
Warnings about capabilities:
Granting capabilities such as SYS_ADMIN is very powerful and can effectively grant broad privileges. Only add capabilities that are strictly necessary for the container workload, and follow the principle of least privilege.
Quick comparison: Pod vs Container security context Best practices
  • Prefer setting minimally required privileges. Use runAsNonRoot: true when possible and limit runAsUser to unprivileged UIDs.
  • Apply Pod-level defaults for consistent baseline behavior across containers, and reserve container-level securityContext for exceptions.
  • Avoid adding powerful capabilities (like SYS_ADMIN) unless absolutely necessary. When you must add them, document why and scope them narrowly.
  • Use readOnlyRootFilesystem: true and drop unnecessary capabilities to reduce attack surface.
  • Test and verify with kubectl describe and kubectl get -o yaml to confirm the effective security settings.
Commands for inspection and troubleshooting
  • View the full manifest: kubectl get pod web-pod -o yaml
  • See events and container-level settings: kubectl describe pod web-pod
  • Check effective filesystem group (fsGroup) behavior by inspecting mounted volumes and file modes
Links and references That covers the essentials of Kubernetes security contexts: where to configure them, which settings apply at the Pod vs container level, and how container-level settings override Pod defaults. Try the examples to practice viewing, configuring, and troubleshooting security contexts in your clusters.

Watch Video

Practice Lab