Pod Security Policies (PSPs) are a cluster-level resource in Kubernetes that controls security-sensitive aspects of pod specifications. For years, they've served as the cornerstone of security enforcement in Kubernetes clusters by ensuring only pods adhering to specific criteria like running as a non-root user, not running privileged containers, and more are deployed, minimizing vulnerability risks. However, after the release of Kubernetes 1.26, PSPs became deprecated, paving the way for a more robust and flexible approach: the Pod Security Admission Controller. If you're looking for a step-by-step migration process with examples, here it is.

What is the Pod Security Admission Controller in Kubernetes 1.26

In Kubernetes 1.26, the Pod Security Admission Controller (PSAC) is a new mechanism to replace Pod Security Policies (PSPs). It uses namespace labels to enforce security policies at different levels: Privileged, Baseline, and Restricted. This approach provides granular control over pod security while reducing administrative overhead.

Why use Pod Security Admission Controller?

• Deprecation of PSP: PSPs are deprecated in Kubernetes 1.21 and removed in 1.25. Continuing to use them leaves clusters without proper security controls. 
• Simplified management: The new system is easier to manage and understand, especially in large clusters. 
• Flexibility: Allows more straightforward application of different security policies to different namespaces. 
• Standardization: Uses predefined security levels, making understanding and communicating security postures easier. 
• Futureproofing: Aligns with Kubernetes' direction, ensuring supported and up-to-date security practices. 
• Performance and scalability: More efficient and scalable, especially in large, multi-tenant clusters.

Example Scenario with PSP in Kubernetes 1.25

Create namespace 

kubectl create namespace security-namespace

Create PSP in `security-namespace`

#psp.yaml 
apiVersion: policy/v1beta1 
kind: PodSecurityPolicy 
metadata: 
  name: security-namespace-psp 
spec: 
  privileged: false 
  runAsUser: 
    rule: MustRunAsNonRoot

Apply the changes

kubectl apply -f psp.yaml

Deploy nginx pod in `security-namespace`

#nginx.yaml 
apiVersion: v1 
kind: Pod 
metadata: 
  name: nginx 
  namespace: security-namespace 
spec: 
  containers: 
  - name: nginx 
    image: nginx:latest 
    securityContext: 
      runAsNonRoot: true

Apply the changes

kubectl apply -f nginx.yaml

Steps to migrate from PSP to Pod Security Admission Controller in Kubernetes 1.26

Step 1. Add Security Labels to Namespace:

#security-namespace-update.yaml 
apiVersion: v1 
kind: Namespace 
metadata: 
  name: security-namespace 
  labels: 
    pod-security.kubernetes.io/enforce: baseline 
    pod-security.kubernetes.io/audit: restricted 
    pod-security.kubernetes.io/warn: restricted

Apply the changes

kubectl apply -f security-namespace-update.yaml

Step 2. Update nginx Pod Definitions:

#nginx.yaml 
apiVersion: v1 
kind: Pod 
metadata: 
  name: nginx 
  namespace: security-namespace 
spec: 
  containers: 
  - name: nginx 
    image: nginx:latest 
    securityContext: 
      runAsNonRoot: true 
      allowPrivilegeEscalation: false

Apply the changes

kubectl apply -f nginx.yaml

Step 3. Remove PSP

kubectl delete psp security-namespace-psp

Verify all pods are running correctly

kubectl get pods --all-namespaces

What are the benefits of Pod Security Admission Controller 

• Ease of use: Simpler setup and management.
• Granular control: Apply different security levels to different namespaces.
• Consistent standards: Predefined security levels across clusters.
• Enhanced security: Better security posture with less effort.

Upgrade your Kubernetes security: Migrate to Pod Security Admission

There was support for PSP till 1.25, however if you are looking to switch to the latest version of K8s (1.28 released in July 2024), you will have to migrate your PSPs. Migrating from PSP to the Pod Security Admission Controller is essential for maintaining a secure and modern Kubernetes environment. By following these steps, you'll ensure that your clusters remain secure and compliant with the latest Kubernetes security practices.