SecurityContext — Pod & Container Hardening

Run containers as non-root, drop Linux capabilities, enforce read-only filesystems, and prevent privilege escalation.

intermediate60 minRead → Lab → Quiz → Practice

🧠 Brain Warm-Up

🧠 Brain Warm-Up: By default, containers run as root (UID 0). If an attacker breaks out of the container, they have root on the host. What fields would you set in a securityContext to minimize this risk?

Pod vs Container securityContext

spec:
  securityContext:          # ← pod-level: applies to all containers
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  - name: app
    securityContext:        # ← container-level: overrides pod-level
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]

Pod-level applies to all containers and init containers.

Container-level overrides pod-level for that specific container.

Key Fields

Field	Level	Effect
`runAsUser`	pod/container	Sets UID for process
`runAsGroup`	pod/container	Sets GID for process
`runAsNonRoot`	pod/container	Rejects UID 0
`fsGroup`	pod	Volume files owned by this GID
`readOnlyRootFilesystem`	container	Prevents writes to container FS
`allowPrivilegeEscalation`	container	Prevents sudo/setUID
`capabilities.drop`	container	Remove Linux capabilities
`capabilities.add`	container	Add specific capabilities
`privileged`	container	Full host access (avoid!)

Linux Capabilities

Instead of root vs non-root, Linux capabilities give fine-grained privileges:

NET_BIND_SERVICE — bind ports < 1024
SYS_ADMIN — various admin operations (powerful, avoid)
CHOWN — change file ownership

Best practice: drop: ["ALL"] then add: ["NET_BIND_SERVICE"] if needed.

The Hardened Baseline

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

This is the minimum you should apply to every production container.

←

PodDisruptionBudgets & Cluster Maintenance

Node Management — Cordon, Drain & Maintenance

→