Blogs

Introduction

With the deprecation of Pod Security Policies (PSP) in Kubernetes 1.21, a new method was needed to ensure pod security. Kubernetes introduced Pod Security Admission (PSA) – a standardized and more flexible solution for enforcing pod security policies.

But what exactly is PSA, how does it work, and why is it essential for organizations running Kubernetes in compliance with regulations like NIS2 or BSI IT-Grundschutz? This post provides a comprehensive overview.

Why Was Pod Security Admission Introduced?

The previous Pod Security Policies (PSP) allowed cluster administrators to define detailed security rules for pods, including:

• Restricting root access

• Controlling access to host file systems

• Limiting network and volume permissions

However, PSPs were complex to manage and lacked flexibility, leading to their removal in Kubernetes 1.25.

The new Pod Security Admission model replaces PSPs with a simpler yet powerful approach to enforcing security policies at the namespace level.

How Pod Security Admission Works

PSA is an admission controller that verifies whether pods comply with a namespace’s security requirements. It defines three predefined security levels:

1. Baseline (Basic Protection)

• Prevents obvious security risks

• Blocks root access, host namespace access, and privilege escalation

• Suitable for general applications

2. Restricted (Strict Security)

• Enforces best practices such as "Run as Non-Root"

• Uses a read-only root file system and restricts unnecessary volume mounts

• Ideal for security-critical applications handling sensitive data

3. Privileged (Full Access)

• Disables security restrictions

• Used only for infrastructure and system pods that require deep cluster access

Defining Security Policies per Namespace

One major advantage of PSA is granular control at the namespace level. Unlike PSPs, which applied to the entire cluster, different security levels can be set per namespace.

How it works:

Assigning Security Levels via Labels

Namespaces are labeled to enforce security policies:

metadata:
  labels:
    pod-security.kubernetes.io/enforce: 'restricted'

This ensures that only pods complying with Restricted policies can be created in this namespace.

Using Audit and Warning Modes

Before enforcing policies, organizations can test them in an evaluation mode:

metadata:
  labels:
    pod-security.kubernetes.io/enforce: 'baseline'
    pod-security.kubernetes.io/audit: 'restricted'
    pod-security.kubernetes.io/warn: 'restricted'

• Warning Mode: Logs violations but does not block deployments

• Audit Mode: Records violations for analysis

• Enforce Mode: Strictly enforces security policies

This gradual implementation helps organizations introduce new security policies without disrupting operations.

Practical Implementation

Here are some examples of how PSA can enhance Kubernetes security:

1. Securing Production Environments

A namespace for production workloads should be secured with Restricted policies:

kubectl label namespaces production pod-security.kubernetes.io/enforce=restricted

2. Testing New Applications

New services can be tested with audit and warning modes before full enforcement:

kubectl label namespaces testing pod-security.kubernetes.io/enforce=baseline \
    pod-security.kubernetes.io/audit=restricted \
    pod-security.kubernetes.io/warn=restricted

3. Exceptions for System Namespaces

Kubernetes system services often require higher privileges. Here, the Privileged level can be applied:

kubectl label namespaces kube-system pod-security.kubernetes.io/enforce=privileged

Conclusion: Why Organizations Should Act Now

Migrating to Pod Security Admission offers a simpler, more secure, and flexible approach to Kubernetes security. Organizations using Kubernetes in critical environments should actively implement PSA to:

• Minimize security risks
• Meet compliance requirements (e.g., NIS2, BSI)
• Future-proof their Kubernetes operations