namespace-security-baseline.yaml

ook architecture introduced non-deterministic delays under load, while PSA operates as a built-in admission plugin evaluated synchronously within the API server request path. The false-positive rate difference highlights a structural improvement: PSA's three-tier standard (Privileged, Baseline, Restricted) aligns with real-world workload patterns, whereas PSP's granular capabilities matrix frequently blocked legitimate sidecars, logging agents, and CSI drivers. Teams migrating from PSP to PSA report 60-70% reduction in security-related deployment rollbacks.

Core Solution

Modern Kubernetes security enforcement no longer relies on PSP. The architecture has shifted to Pod Security Standards (PSS) enforced via Pod Security Admission (PSA). PSA is a built-in admission controller that evaluates pods against namespace-level labels. It requires no external components, no RBAC policy grants, and introduces negligible latency.

Architecture Decision & Rationale

PSA operates at the kube-apiserver level. When a pod creation request arrives, the admission chain checks the target namespace for pod-security.kubernetes.io/enforce, audit, and warn labels. If present, the pod spec is validated against the corresponding PSS level. This label-driven model decouples policy definition from RBAC, eliminates webhook latency, and enables progressive enforcement via warn and audit modes before switching to enforce.

Step-by-Step Implementation

1. Audit existing workloads for PSP dependencies Identify clusters running <1.25 with active PSPs. Extract policy definitions and map constraints to PSS equivalents:

   • privileged: true → Privileged level
   • runAsNonRoot: true, allowPrivilegeEscalation: false, restricted volumes → Restricted level
   • Default deny capabilities, non-root enforcement, seccomp profiles → Baseline level

2. Apply namespace labels for progressive enforcement Start with warn mode to capture violations without blocking deployments:

   apiVersion: v1
   kind: Namespace
   metadata:
     name: production-apps
     labels:
       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: restricted
       pod-security.kubernetes.io/warn-version: latest
   

3. Validate workload compatibility Deploy test workloads and monitor API server audit logs and kubectl warnings. PSA emits structured warnings for non-compliant pods:

   kubectl get events -n production-apps --field-selector reason=Forbidden
   kubectl logs -n kube-system -l component=kube-apiserver | grep -i pod-security
   

4. Remediate violations Common remediation paths:

   • Remove hostNetwork: true and hostPID: true
   • Set securityContext.runAsNonRoot: true
   • Drop all capabilities and add only required ones:

     securityContext:
       capabilities:
         drop: ["ALL"]
         add: ["NET_BIND_SERVICE"]
     

   • Apply seccomp profiles:

     securityContext:
       seccompProfile:
         type: RuntimeDefault
     

5. Transition to enforce mode Once audit logs show zero critical violations for 7-14 days, switch enforcement:

   pod-security.kubernetes.io/enforce: restricted
   pod-security.kubernetes.io/enforce-version: latest
   

Code Example: Compliant Pod Manifest

apiVersion: v1
kind: Pod
metadata:
  name: secure-web-app
  namespace: production-apps
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: myregistry/webapp:2.1.0
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: ["ALL"]
        readOnlyRootFilesystem: true
      volumeMounts:
        - name: tmp
          mountPath: /tmp
  volumes:
    - name: tmp
      emptyDir: {}

Pitfall Guide

1. Assuming PSP still functions on v1.25+ clusters PSP API objects are silently ignored. Clusters upgraded past 1.24 will not enforce PSP rules, creating a false sense of security. Always verify cluster version and replace PSP references with PSA namespace labels.

2. Misconfiguring PSA label hierarchy PSA evaluates enforce, audit, and warn independently. Setting enforce: baseline while warn: restricted creates conflicting signals. The enforcement level dictates admission; warn/audit only generate telemetry. Align levels progressively: start with enforce: baseline, then tighten to restricted after remediation.

3. Blocking legitimate system components DaemonSets (Fluentd, Calico, Node Problem Detector) and CSI drivers frequently require privileged: true, host mounts, or NET_ADMIN capabilities. Applying restricted enforcement cluster-wide breaks node-level infrastructure. Use namespace isolation: system namespaces receive privileged or baseline labels, application namespaces receive restricted.

4. Ignoring init container security contexts PSA evaluates the entire pod spec, including init containers. A compliant main container paired with a root-running init container will be rejected under restricted enforcement. Ensure all containers in the pod spec share consistent security contexts.

5. Skipping warn mode validation Jumping directly to enforce: restricted causes immediate deployment failures in legacy workloads. Always run a 14-day warn/audit cycle to capture capability requirements, volume access patterns, and runtime dependencies before blocking.

6. Confusing PSA with NetworkPolicy or RuntimeClass PSA controls pod creation constraints (user, capabilities, volumes, host namespaces). It does not restrict network traffic (NetworkPolicy) or container runtime selection (RuntimeClass). Security baselines require layered controls; PSA is the admission gate, not the full stack.

7. Overlooking service account token automounting PSA does not disable service account token projection by default. Attackers who compromise a container can mount the default token and escalate to the API server. Always set automountServiceAccountToken: false unless explicitly required, and pair with RBAC least privilege.

Production Bundle

Action Checklist

• Audit cluster version and verify PSP deprecation status; upgrade or migrate if <1.25
• Inventory all active PSP objects and map constraints to PSS levels (Privileged/Baseline/Restricted)
• Apply PSA namespace labels using progressive enforcement (warn → audit → enforce)
• Validate system namespaces separately; isolate infrastructure workloads from application namespaces
• Run 14-day audit/warn cycle; remediate capability, volume, and user violations
• Disable automountServiceAccountToken for all application pods unless API access is required
• Enable API server audit logging for pod-security.kubernetes.io events
• Document exception process for legacy workloads requiring baseline or privileged labels

Decision Matrix

Scenario	Recommended Approach	Why	Cost Impact
New cluster deployment	PSA restricted enforcement from day one	Native admission, zero external dependencies, aligns with CIS benchmarks	Low (configuration only)
Legacy monolith with root dependencies	PSA baseline + namespace isolation + runtime monitoring	Maintains compatibility while blocking privilege escalation and host access	Medium (monitoring tooling + refactoring backlog)
Multi-tenant platform with third-party workloads	PSA warn + OPA/Gatekeeper for custom constraints	PSA enforces baseline; OPA handles org-specific policy without API latency penalty	High (controller overhead + policy authoring)
Compliance-driven environment (SOC2/PCI)	PSA restricted + CIS K8s benchmark automation + audit log shipping	Meets regulatory requirements for least privilege, immutable filesystems, and non-root execution	Medium (audit pipeline + compliance reporting)

Configuration Template

# namespace-security-baseline.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: app-production
  labels:
    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: restricted
    pod-security.kubernetes.io/warn-version: latest
---
# pod-security-restricted.yaml
apiVersion: v1
kind: Pod
metadata:
  name: secure-workload
  namespace: app-production
spec:
  automountServiceAccountToken: false
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 3000
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: internal.registry/app:v3.2.1
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]
      resources:
        limits:
          cpu: "500m"
          memory: "256Mi"
        requests:
          cpu: "100m"
          memory: "64Mi"
      volumeMounts:
        - name: tmp
          mountPath: /tmp
        - name: cache
          mountPath: /var/cache/app
  volumes:
    - name: tmp
      emptyDir: {}
    - name: cache
      emptyDir:
        sizeLimit: 100Mi

Quick Start Guide

1. Verify cluster version: Run kubectl version --short. If server version is ≥1.25, PSP is removed. Proceed to PSA configuration.
2. Label target namespace: Apply the three-tier PSA labels (enforce, audit, warn) with baseline enforcement and restricted warn/audit.
3. Deploy a test workload: Submit a pod with securityContext.runAsNonRoot: true and allowPrivilegeEscalation: false. Verify admission succeeds and warnings appear if constraints are violated.
4. Review audit logs: Check kubectl get events and API server logs for pod-security.kubernetes.io violations. Document required capabilities or volume access.
5. Tighten enforcement: After 7-14 days of zero critical warnings, update the namespace label to pod-security.kubernetes.io/enforce: restricted. Monitor deployment pipelines for admission rejections and adjust application manifests accordingly.