Pod Security Standards: Hardening the Container Runtime

In a perfect world, a container is a sandbox. It shouldn't be able to "See" the other containers, and it definitely shouldn't be able to "Break out" into the host operating system. But by default, Linux containers have many powerful capabilities that a hacker can exploit to perform a Container Escape.

To prevent this, Kubernetes uses Pod Security Standards (PSS).

PSS is a set of pre-defined security profiles that you can apply to your namespaces. Instead of writing complex, 100-line security policies, you just label your namespace as "Restricted," and Kubernetes will automatically block any pod that tries to do something dangerous—like running as the root user or mounting the host's filesystem.

In this lesson, we will master the three levels of PSS: Privileged, Baseline, and Restricted. We will learn how to enforce these policies, how to audit existing pods, and how to build a production-ready "Baseline" for all your AI microservices.

1. The Three Security Levels

Kubernetes provides three standardized profiles of increasing strictness.

A. Privileged (Level 0)

Strictness: None.
Usage: Only for infrastructure pods (like CNI plugins or logging agents) that actually need to control the hardware.
Security: Extremely dangerous for applications. Do not use for FastAPI or Next.js.

B. Baseline (Level 1 - The Default Minimum)

Strictness: Prevents known privilege escalations.
Features: Blocks privileged: true, blocks hostPath volumes, and blocks sharing the host's network or process ID (PID).
Usage: The recommended minimum for every application namespace.

C. Restricted (Level 2 - The Gold Standard)

Strictness: Heavy hardening.
Features: Requires containers to run as a Non-Root User, prevents adding new Linux capabilities, and requires the filesystem to be Read-Only.
Usage: Essential for highly secure environments (Finance, Healthcare, Defense).

2. Enforcing Policies with Namespace Labels

Applying a security policy is as simple as adding a label to your namespace.

apiVersion: v1
kind: Namespace
metadata:
  name: ai-prod
  labels:
    # 1. Enforce: Block any pod that violates "Baseline"
    pod-security.kubernetes.io/enforce: baseline
    # 2. Audit: Record violations of "Restricted" in the logs
    pod-security.kubernetes.io/audit: restricted
    # 3. Warn: Show a warning to the developer during 'kubectl apply'
    pod-security.kubernetes.io/warn: restricted

3. What Happens During a Violation?

If a developer tries to deploy a pod with securityContext.privileged: true into the ai-prod namespace:

The Admission Controller intercepts the request.
It sees the enforce: baseline label.
It compares the pod's YAML to the baseline rules.
It rejects the request with an error message: Error from server (Forbidden): pods "buggy-pod" is forbidden: violates PodSecurity "baseline:v1.28".

4. Visualizing the Security Barrier

graph LR
    Dev["Developer"] -- "Apply Pod (Privileged)" --> API["API Server"]
    
    subgraph "Admission Control"
        PSS["Pod Security Standard Check"]
    end
    
    API -- "Request" --> PSS
    PSS -- "Matches Namespace Label?" --> Decision{"Validate"}
    
    Decision -- "Fail" --> Error["Return 403 Forbidden"]
    Decision -- "Pass" --> Node["Schedule to Node"]

5. SecurityContext: The Developer's Shield

To satisfy a "Restricted" policy, you must define a securityContext in your Pod YAML.

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
  containers:
  - name: ai-agent
    image: my-ai-agent:latest
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true # Prevent hackers from installing malware
      capabilities:
        drop: ["ALL"]

6. Practical Example: Auditing Your Cluster

Before you "Enforce" a policy, you should "Audit" it to see how many of your current pods would break.

# Label the namespace to 'warn' only
kubectl label ns my-namespace pod-security.kubernetes.io/warn=restricted --overwrite

# Then, run any apply or check the logs
# You will see warnings for every pod that isn't compliant.

7. AI Implementation: Running Untrusted Models Safely

If you are running an AI experiment that involves executing dynamic code (e.g. a PythonREPLTool inside a LangChain agent), that container is a high-risk asset.

The AI Sandbox Strategy:

Restricted Policy: Force the pod to run with readOnlyRootFilesystem: true. This ensures that even if the AI "hallucinates" a command to delete /etc, it will fail because the disk is read-only.
No Capabilities: Drop all Linux capabilities. The AI doesn't need to change the system clock or manage network interfaces.
AppArmor/Seccomp: Use advanced security profiles to limit exactly which system calls the AI process can make.

8. Summary and Key Takeaways

Pod Security Standards: The built-in replacement for the old PodSecurityPolicy.
Baseline: The "Common Sense" security level for all pods.
Restricted: The choice for high-security production environments.
Enforcement: Handled via simple namespace labels.
SecurityContext: The per-pod settings required to meet the standards.
Defense in Depth: PSS is the final barrier between a compromised container and your hardware.

In the next lesson, we will shift our focus to the "Supply Chain": Image Security and Scanning.

9. SEO Metadata & Keywords

Focus Keywords: Kubernetes Pod Security Standards tutorial, PSS levels privileged baseline restricted, enforcing PSS namespace labels, securityContext K8s best practices, pod-security.kubernetes.io/enforce, hardening AI containers Kubernetes.

Meta Description: Secure your Kubernetes pods with professional-grade standards. Learn how to use the built-in Pod Security Standards to prevent container escapes, enforce non-root execution, and safeguard your infrastructure against malicious workloads.

Pod Security Standards (Privileged, Baseline, Restricted)