How do you harden a pod with securityContext and Pod Security standards?
Quick Answer
Use securityContext to run as a non-root user, drop Linux capabilities, use a read-only root filesystem, and disallow privilege escalation. Enforce these cluster-wide with Pod Security Admission (baseline/restricted) or a policy engine.
Detailed Answer
By default containers can run as root with broad capabilities — a big blast radius if compromised. securityContext tightens this per-pod/container: runAsNonRoot + runAsUser to avoid root, allowPrivilegeEscalation: false, readOnlyRootFilesystem: true (write only to mounted volumes), drop ALL capabilities and add back only what's needed, and seccompProfile: RuntimeDefault to filter syscalls. To enforce standards fleet-wide, Pod Security Admission applies one of three levels per namespace — privileged (no restrictions), baseline (blocks known-bad), restricted (hardened defaults like non-root, no privilege escalation). For richer policy (image provenance, required labels), teams add OPA Gatekeeper or Kyverno as admission controllers. The goal is least privilege: a container should have exactly the OS-level powers it needs and nothing more, enforced automatically rather than left to each author.
Code Example
securityContext:
runAsNonRoot: true
runAsUser: 10001
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities: { drop: ["ALL"] }
seccompProfile: { type: RuntimeDefault }
# enforce: kubectl label ns app pod-security.kubernetes.io/enforce=restrictedInterview Tip
List the concrete knobs (runAsNonRoot, drop ALL caps, readOnlyRootFilesystem, no privilege escalation) then name the enforcement layer (Pod Security Admission restricted, or Kyverno/Gatekeeper). Specifics beat 'make it secure.'