How does Pod Security Standards (restricted) work, and how do you enforce it across all namespaces in a bank?
Quick Answer
Pod Security Standards define three security profiles (privileged, baseline, restricted) enforced by the built-in Pod Security Admission controller through namespace labels. The restricted profile blocks root containers, requires read-only root filesystems, drops all capabilities, prevents privilege escalation, and enforces seccomp profiles. Banks deploy in audit mode first, remediate violations, then switch to enforce mode.
Detailed Answer
Think of Pod Security Standards like building codes for construction in a financial district. The city defines three tiers of building standards: unrestricted (build anything, used only for approved infrastructure like power plants), baseline (standard safety requirements like fire exits and load-bearing walls), and restricted (highest safety standards with earthquake reinforcement, blast resistance, and redundant systems, required for buildings that house critical financial operations). Every building permit application is checked against the appropriate standard before construction begins, and buildings that violate their zone's requirements are rejected. Pod Security Standards work the same way for Kubernetes workloads.
The Pod Security Admission controller is built into Kubernetes since version 1.25 and replaces the deprecated PodSecurityPolicy. It evaluates pod specifications against three predefined profiles. The privileged profile imposes no restrictions and is reserved for system-level workloads like CNI plugins and logging agents that genuinely need host access. The baseline profile blocks known privilege escalation vectors like hostNetwork, hostPID, and privileged containers while allowing most standard workloads. The restricted profile enforces the tightest controls: containers must run as non-root, must drop ALL Linux capabilities, must use a read-only root filesystem, cannot use hostPath volumes, must define a seccomp profile, and must set allowPrivilegeEscalation to false.
Enforcement is configured through namespace labels, not cluster-wide switches. Each namespace receives labels specifying the desired profile and the enforcement mode. Three modes exist: enforce blocks pods that violate the profile, audit logs violations without blocking, and warn displays warnings to the user creating the pod. In banking environments, the rollout strategy is critical. Applying enforce mode immediately across all namespaces would break running workloads that do not yet comply. Instead, teams start by labeling all namespaces with audit and warn modes using the restricted profile. This generates logs and warnings showing exactly which pods and controllers violate the restricted standard without disrupting production. Teams then remediate violations by updating Deployments, StatefulSets, and DaemonSets to comply with the restricted profile.
The remediation process involves specific changes to pod specifications. Container images must be rebuilt to run as non-root users with specific UIDs. Security contexts must set runAsNonRoot: true, readOnlyRootFilesystem: true, allowPrivilegeEscalation: false, and capabilities: drop: ["ALL"]. Applications that need to write temporary files must use emptyDir volumes mounted at specific paths rather than writing to the root filesystem. After all workloads in a namespace pass the audit check with zero violations, the namespace label is changed from audit to enforce. This progressive rollout typically takes weeks across a large banking platform because each application team must verify their workloads function correctly under the restricted profile.
The production gotcha in banking environments is handling legitimate exceptions. Some workloads genuinely require elevated permissions: Vault Agent sidecars may need IPC capabilities, monitoring DaemonSets need hostPath access for node metrics, and network policy controllers need hostNetwork. These workloads run in dedicated system namespaces labeled with baseline or privileged profiles, and the exception is documented with a security review justification. The danger is exception creep: over time, teams request exceptions for convenience rather than necessity. Mature organizations require security team approval for any namespace that does not use the restricted profile, and they audit exception namespaces quarterly as part of OCC compliance reviews. Another subtle issue is that Pod Security Admission only evaluates pod specifications, not the controllers that create them. A Deployment with a non-compliant pod template will only fail when the ReplicaSet tries to create a pod, not when the Deployment itself is applied. The warn mode catches this at apply time, which is why banking teams always enable warn alongside enforce.