ReviseAlgo Logo

RBAC & Security

Pod Security Standards — Restricting What Pods Can Do

Implementing Privileged, Baseline, and Restricted security settings.

Last Updated: June 15, 2026 • 15 min read

Introduction

Securing the cluster APIs with RBAC is only half the battle. If a developer can run a container with root access, mount the host node's filesystem, or share host network ports, they can bypass API authorization rules entirely.

Pod Security Standards (PSS) define security profiles to restrict container privileges. The Pod Security Admission (PSA) controller enforces these standards at the namespace boundary during pod creation requests.

Why It Matters

By default, containers can run as root and write directly to host filesystems. A compromised container could execute a host-namespace escape, scan local host memory, monitor physical node network interfaces, or delete adjacent container volumes.

Real-World Analogy

Think of Pod Security Standards like **tenant lease agreements in a shared apartment complex**.

  • Privileged Profile (Unrestricted): An industrial tenant allowed to remodel walls, modify structural beams, and use heavy machinery (unlocked system capabilities).
  • Baseline Profile (Standard): A residential tenant allowed to live normally but blocked from knocking down walls or bringing high-risk industrial gear (preventing known escalations).
  • Restricted Profile (Hardened): A temporary hotel guest blocked from making any modifications, forced to use plastic cutlery, and forbidden from locking their doors or bringing outside guests (strictly locked context).

How It Works

The built-in Pod Security Admission controller runs as an admission webhook component. When a deployment creates pods, the API Server sends the spec to the controller. The controller reads target namespace labels to find the active security mode. If the pod spec violates the configured profile (e.g. running as root in a namespace labeled for Restricted enforce), the controller blocks the request, returning validation error strings to the client.

Internal Architecture

Security standards restrict access to Linux kernel isolation mechanisms. The Restricted standard enforces parameters inside the pod's securityContext:

  • Linux Capabilities: Blocks access to node kernel calls by dropping ALL default system capabilities.
  • Root Blocking: Enforces runAsNonRoot: true, meaning container startup fails if the UID points to root (UID 0).
  • Filesystem Lock: Enforces readOnlyRootFilesystem: true to prevent container write operations outside of mounted directories.

Visual Explanation

Loading diagram…

Practical Example

Here is a secure namespace configuration and a fully hardened pod manifest that satisfies the Restricted security profile.

1. Secure Namespace with PSA Labels

2. Hardened Pod Manifest (restricted-pod.yaml)

Common Mistakes

  • Privileged Pods: Setting privileged: true inside container context without absolute operational need (like CNI plugins).
  • Root Execution: Building Dockerfiles that do not define a non-root USER statement, failing PSA validation.
  • Host Namespace Leaks: Setting hostNetwork: true or hostPID: true inside the pod specification.

Quick Quiz

Q1: Which Pod Security Standard profile should be used for typical microservices that do not need system host network access?

A) Privileged

B) Restricted

C) RootOnly

D) HostNamespace

Answer: B — The 'Restricted' profile enforces security hardening best practices (non-root, dropped capabilities, read-only filesystems), drastically reducing container escape risks.

Q2: What happens if you modify a namespace's PSA label from audit to enforce while pods are already running?

A) Running pods are immediately terminated by the control plane.

B) Existing running pods continue to run unaffected; the admission controller only evaluates new pod creation requests.

C) The namespace is deleted.

D) Pod logs are cleared.

Answer: B — PSA is an admission controller. It checks specifications during the admission API phase. Changing labels to 'enforce' will block future pods or updates from violating the rules, but won't eject currently running pods.

Scenario-Based Challenge

Production Scenario:

You configure a namespace for Restricted enforcement. A developer attempts to deploy a legacy container, but it fails to compile because it attempts to write temporary lock files to /run/app.lock. The developer demands you disable the read-only filesystem policy. How do you resolve this securely?

View Solution

Do not disable readOnlyRootFilesystem. Instead, mount a temporary directory (emptyDir) in memory specifically at the path the application needs write access to:

1. Modify the Pod spec to define an emptyDir volume:


2. Mount this volume inside the container volumeMounts at /run:
This permits the legacy application to write files to /run without exposing the root filesystem.

Debugging Exercise

Broken Configuration:

A developer deploys a pod to a Restricted namespace, but the API Server rejects it with this error: x509: Pod violates Restricted profile: runAsNonRoot must be true, capabilities.drop must be [ALL]. Here is the broken manifest spec:

View Debugging Steps & Fix

Reason: The container specifies no root-blocking boundaries or capability blocks. The Restricted standard requires explicit security enforcement blocks.

The Fix: Add non-root checks and drop default capabilities inside the container's securityContext block:

Interview Questions

1. Conceptual: Why did Kubernetes deprecate PodSecurityPolicies (PSP) in favor of Pod Security Standards (PSS)?

PodSecurityPolicies were complex, difficult to debug, and prone to silent failures because permissions were coupled to RoleBindings. They created high operational risks (accidentally locking out nodes during upgrades). PSS/PSA simplifies security by defining three clear, standard profiles applied directly to namespaces using labels, eliminating permission-lookup overhead.

2. Technical: What does allowPrivilegeEscalation: false accomplish under the hood in Linux?

It maps directly to the kernel flag PR_SET_NO_NEW_PRIVS. This prevents child processes of the container from gaining more privileges than the parent process. For example, it blocks execution of binaries with the setuid or setgid bits (like sudo or passwd), preventing local privilege escalation attacks.

Production Considerations

Enforce Baseline or Restricted security profiles on all non-system namespaces. For highly sensitive namespaces, use advanced policy engines like Open Policy Agent (OPA) Gatekeeper or Kyverno to define custom validation policies that PSA cannot check.