← Lessons

quiz vs the machine

Gold1400

Security

The Pod Security Standards

How pod level controls restrict privileges, host access, and capabilities to keep workloads contained.

5 min read · core · beat Gold to climb

Why Restrict Pods

A pod that runs as root, mounts host paths, or requests privileged mode can endanger the whole node. Pod security controls define what a pod is allowed to request so risky settings are rejected before the pod starts.

What They Restrict

  • Privileged containers that gain broad host access.
  • Host namespaces such as the host network or process space.
  • Root execution when a non root user would suffice.
  • Dangerous capabilities and writable host paths.

Standard Levels

Modern Kubernetes groups these rules into named profiles applied per namespace.

  • Privileged places no restrictions, for trusted system workloads only.
  • Baseline blocks the most known privilege escalations.
  • Restricted enforces hardening such as non root and dropped capabilities.

A namespace can warn, audit, or fully enforce a profile.

Enforcement at Admission

These checks run at admission, when the pod spec is submitted. A pod that violates the namespace profile is rejected, so the cluster never schedules it.

Key idea

Pod security controls restrict privileged mode, host namespaces, root execution, and capabilities through named profiles, rejecting non compliant pods at admission so dangerous workloads never schedule.

Check yourself

Answer to earn rating on the learn ladder.

1. When are pod security rules enforced?

2. Which standard level enforces the strongest hardening?

3. Why block host namespaces for most pods?