🔐 How to Implement Pod Security Standards in Kubernetes 1.25+

A Complete Guide to Strengthen Your Cluster’s Pod-Level Security

Kubernetes makes it easy to run applications at scale — but securing those apps? That’s a different story.

Starting from Kubernetes v1.25, the legacy PodSecurityPolicy (PSP) has been removed, and replaced by Pod Security Standards (PSS) — a simpler, namespaced-based way to control what Pods can and cannot do.

In this blog, we’ll explore what PSS is, why it matters, and step-by-step how to implement it — from beginner to production-grade setups.

🔎 What Are Pod Security Standards (PSS)?

PSS define a set of recommended security profiles for Pods, categorized into three levels:

These levels apply to Pod specifications like:

• Running as root
• Host networking/IPC
• Privileged containers
• Volume types (hostPath, etc.)
• Capabilities like NET_ADMIN

🧭 Step 1: Understand the Enforcement Modes

PSS is enforced per namespace using labels and admission control.

Three enforcement modes:

You can use one or all three modes simultaneously.

⚙️ Step 2: Enable Pod Security Admission (PSA) in Kubernetes

As of v1.25+, the PodSecurity admission controller is built-in and enabled by default.
No need to install anything — it’s ready to use.

📁 The controller works by applying labels to namespaces.

🛠️ Step 3: Label Your Namespaces

Use the following label format:

php-templateCopyEditpod-security.kubernetes.io/<mode>: <level>

Example:

bashCopyEditkubectl label ns dev \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/enforce-version=latest \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

This setup:

• Blocks pods violating baseline rules
• Audits and warns on anything violating restricted rules

📌 Pro Tip:

Use "latest" or pin to a version:

bashCopyEditpod-security.kubernetes.io/enforce-version=latest

🔍 Step 4: Test It (Create Violating Pod)

Try creating an insecure pod:

yamlCopyEditapiVersion: v1
kind: Pod
metadata:
  name: test-root
spec:
  containers:
  - name: root
    image: busybox
    command: ["sh", "-c", "sleep 3600"]
    securityContext:
      runAsUser: 0

This should be:

• Blocked under enforce=restricted
• Warned under warn=restricted

🧪 Step 5: View Violations (Audit Logs)

Check events or audit logs:

bashCopyEditkubectl get events --namespace dev

Look for warnings like:

pgsqlCopyEditpod-security.kubernetes.io/warn: violates restricted policy

These help you gradually harden your policies without breaking apps.

🧩 Step 6: Apply Policies Based on Environments

Define policy strictness based on risk tolerance.

📊 Step 7: Visualize Violations (Optional Tools)

Use tools to analyze and audit Pod specs for security compliance:

• OPA/Gatekeeper — custom policies with Rego
• Kyverno — policy as code with Kubernetes-native syntax
• kubectl-who-can — understand RBAC access
• Trivy — scan pods for CVEs and misconfigs

🧠 Advanced Practices

✅ Default Labels via Admission Webhooks

Use automation tools (like Kyverno or OPA) to automatically apply PSS labels to every new namespace.

✅ Policy Drift Detection

Set up GitOps (e.g., ArgoCD) to prevent unauthorized label changes.

✅ Combine with Runtime Security

PSS protects before deployment. Pair it with tools like Falco or Sysdig for runtime detection.

🧰 Tools Recap

🚀 Final Thoughts

With Pod Security Policies gone in K8s 1.25+, PSS and PSA are the new standard — and honestly, they’re simpler and more flexible.

To summarize:

Lock down your pods, namespace by namespace — because in cloud-native, security isn’t optional.

Mohammad Gufran Jahangir