Day 66: Pod Security Standards

Constraining what a Pod is allowed to do, not just to

RBAC controls access to the API; Pod Security Standards control what a Pod's own containers are allowed to do at runtime — run as root, mount the host filesystem, use host networking, gain extra capabilities. Kubernetes defines three levels: Privileged (no restrictions), Baseline (blocks known privilege escalations), Restricted (heavily locked down — non-root, no privilege escalation, dropped capabilities).

A Restricted-style Pod securityContext

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  allowPrivilegeEscalation: false
  capabilities:
    drop: ['ALL']
  seccompProfile:
    type: RuntimeDefault

This is Phase 6's capability-dropping, formalized as cluster policy

Instead of remembering to add --cap-drop=ALL to every docker run by hand (Phase 6), Pod Security Standards let you enforce this as a namespace-wide policy — any Pod that doesn't meet the standard is rejected at admission time (tomorrow's topic).

Key terms

Pod Security Standards: Kubernetes's built-in levels (Privileged/Baseline/Restricted) constraining what a Pod's containers may do at runtime.
runAsNonRoot: A securityContext setting rejecting a container that tries to run as UID 0.

Explain the difference between what RBAC controls and what Pod Security Standards control
Write a securityContext enforcing non-root, no privilege escalation, and dropped capabilities

What is the key difference between RBAC and Pod Security Standards?

Day 66: Pod Security Standards

Constraining what a Pod is allowed to do, not just to

We use cookies