Pod Security Admission

Pod Security Admission is a built-in Kubernetes admission controller that enforces security policies on pods at creation time. It replaced the deprecated Pod Security Policies in Kubernetes v1.25 and provides a simpler, more standardized approach to pod security governance.

Warning

Pod Security Policies (PSP) were deprecated in Kubernetes v1.21 and removed in v1.25, they should not be used. Pod Security Admission is the recommended replacement for enforcing pod security standards.

What is Pod Security Admission?

Pod Security Admission is a webhook admission controller that validates pods against predefined security standards before they are created or updated in a Kubernetes cluster. It acts as a gatekeeper, ensuring that only pods meeting specific security criteria are allowed to run.

The controller evaluates pods against three built-in security profiles that represent different levels of security restrictions, from highly permissive to highly restrictive. This approach provides a standardized way to enforce security policies across different Kubernetes environments.

Core Concepts

Pod Security Standards

Pod Security Standards define three security profiles that represent different security postures:

Profile	Purpose	Use Cases	Security Level	Risk Level
Privileged	Unrestricted policy, widest possible permissions	System-level workloads, infrastructure pods, debugging	Minimal restrictions, allows privileged containers and host access	High – should only be used when necessary
Baseline	Minimally restrictive, prevents known privilege escalations	Most standard applications and workloads	Moderate restrictions, blocks common attack vectors	Medium – good balance between security and functionality
Restricted	Heavily restricted, follows pod hardening best practices	Security-critical applications, compliance workloads	High restrictions, enforces defence-in-depth principles	Low – maximum security, potential functionality limitations

Policy Modes

Pod Security Admission operates in three different modes for each namespace:

Mode	Behaviour	Impact	Use Case	Risk
Enforce	Rejects pods that violate the security standard	Prevents non-compliant pods from being created	Production environments where compliance is mandatory	May break applications that don’t meet requirements
Audit	Allows pods to be created but logs policy violations	No immediate operational impact, generates audit logs	Monitoring compliance without blocking workloads	Low operational risk, provides visibility
Warn	Allows pods to be created but shows warnings to users	Provides immediate feedback to developers and operators	Educational environments or gradual policy introduction	Low operational risk, helps with awareness

How Pod Security Admission Works

Admission Control Process

When a pod is submitted to the Kubernetes API server for creation or update, the Pod Security Admission controller is automatically invoked as part of the admission control process. The controller evaluates the pod against the security standards configured for its namespace, determining whether the pod complies with the relevant profile.

The policy and mode to apply are determined by namespace annotations. Each namespace can be annotated to specify which Pod Security Standard (privileged, baseline, or restricted) and which policy mode (enforce, audit, warn) should be used. For example:

apiVersion: v1
kind: Namespace
metadata:
    name: my-app-namespace
    annotations:
        pod-security.kubernetes.io/enforce: "baseline"
        pod-security.kubernetes.io/enforce-version: "latest"
        pod-security.kubernetes.io/audit: "restricted"
        pod-security.kubernetes.io/audit-version: "latest"
        pod-security.kubernetes.io/warn: "baseline"
        pod-security.kubernetes.io/warn-version: "latest"

These annotations tell the controller which profile and mode to use for pods in that namespace. Depending on the policy mode in effect — enforce, audit, or warn — the controller will either allow the pod, reject it, log any violations, or issue warnings to the user. Finally, the API server communicates the admission decision back to the client, completing the workflow.

Security Standard Evaluation

The controller examines various aspects of the pod specification:

Category	Control	Description
Container Security Context	Privileged Containers	Checks if containers run with privileged access
Container Security Context	Capabilities	Evaluates Linux capabilities granted to containers
Container Security Context	User ID	Verifies if containers run as root or non-root users
Container Security Context	Security Context	Examines securityContext settings for containers and pods
Volume and Mount Restrictions	Host Path Volumes	Restricts access to host filesystem paths
Volume and Mount Restrictions	Volume Types	Controls which volume types are permitted
Volume and Mount Restrictions	Mount Points	Evaluates mount paths and permissions
Volume and Mount Restrictions	Subpath Restrictions	Limits subpath mount usage
Network and Host Access	Host Network	Controls access to host networking
Network and Host Access	Host Ports	Restricts binding to host ports
Network and Host Access	Host PID/IPC	Limits access to host process and IPC namespaces
Network and Host Access	Host Users	Controls user namespace sharing
Resource and Behavioural Controls	Resource Limits	Evaluates resource constraints and limits
Resource and Behavioural Controls	Sysctls	Restricts system parameter modifications
Resource and Behavioural Controls	Proc Mount	Controls /proc filesystem mount types
Resource and Behavioural Controls	Seccomp	Evaluates seccomp profile usage

Benefits of Pod Security Admission

Category	Benefit	Details
Enhanced Security Posture	Attack Surface Reduction	Principle of Least Privilege: Enforces minimal necessary permissions Container Escape Prevention: Blocks common container escape techniques Privilege Escalation Protection: Prevents unauthorized privilege escalation Host System Protection: Limits access to host resources and namespaces
Enhanced Security Posture	Standardized Security Policies	Consistent Enforcement: Same security standards across all environments Industry Best Practices: Based on community-agreed security practices Reduced Configuration Complexity: Eliminates need for custom policy definitions Vendor Neutrality: Works consistently across different Kubernetes distributions
Operational Benefits	Simplified Management	Built-in Controller: No additional components to install or maintain Namespace-based Configuration: Granular control at the namespace level Multiple Policy Modes: Flexible enforcement options for different scenarios Gradual Adoption: Ability to introduce policies progressively
Operational Benefits	Developer Experience	Clear Feedback: Immediate warnings and error messages for policy violations Predictable Behaviour: Consistent policy enforcement across environments Educational Value: Helps developers understand security best practices Debugging Support: Audit logs provide visibility into policy decisions
Compliance and Governance	Regulatory Compliance	Audit Trail: Comprehensive logging of policy decisions and violations Consistent Enforcement: Ensures compliance policies are uniformly applied Risk Reduction: Minimizes security vulnerabilities in deployed workloads Documentation: Clear policy definitions for compliance reporting
Compliance and Governance	Security Governance	Policy as Code: Security policies defined in Kubernetes manifests Version Control: Policy changes tracked through standard DevOps processes Automated Enforcement: Reduces human error in security policy application Centralized Control: Security teams can enforce policies across all namespaces

Advantages Over Pod Security Policies

Pod Security Admission improves on Pod Security Policies (PSP) by being built-in, requiring no extra components or complex RBAC. It uses simple namespace annotations for configuration and supports flexible enforcement modes (enforce, audit, warn). Error messages are clearer, and policy management is easier. Regular updates ensure alignment with best practices, and consistent behaviour is guaranteed across Kubernetes environments.