Kubernetes Pod Security Standards (PSS) & Native Admission Control

Production guide on enforcing Privileged, Baseline, and Restricted Pod Security Standards (PSS) using native Kubernetes admission controllers.

Executive Summary & Key Takeaways

• Pod Security Levels: Enforce Privileged, Baseline, or Restricted security profiles at the namespace level.
• Native Admission Controller: Replace legacy PodSecurityPolicies (PSP) with built-in Pod Security Admission (PSA).
• Non-Root Enforcement: Block containers running as root (UID 0) or requesting privilege escalation (allowPrivilegeEscalation=false).
• Audit & Warn Modes: Test security standards across production namespaces without breaking existing pod workloads.

1. Pod Security Standards (PSS) Level Architecture

With the deprecation of PodSecurityPolicy (PSP), Kubernetes introduced native Pod Security Admission (PSA) to enforce Pod Security Standards (PSS) out of the box.

PSS defines three distinct security profiles: Privileged (unrestricted access for system daemons), Baseline (prevents known privilege escalations), and Restricted (hardened security best practices for application workloads).

By configuring namespace labels, cluster administrators enforce admission controls dynamically without installing external webhooks.

Namespace security modes support enforce, audit, and warn modes simultaneously, allowing smooth security transitions.

Enforcing Restricted PSS rules across production namespaces eliminates common container privilege escalation vectors.

Built-in admission evaluation operates directly in the API server without external network latency.

Implementing automated continuous monitoring across production nodes ensures that compliance policies remain enforced during infrastructure updates.

Regular security audits should be integrated into DevOps CI/CD pipelines to verify that system configurations conform to zero-trust architecture standards.

Documenting system architecture and access control rules facilitates compliance verification during independent third-party security audits.

Enforcing strict runtime isolation boundaries prevents privilege escalation vectors across multi-tenant cloud environments.

# Label Namespace to Enforce Restricted Pod Security Standard
apiVersion: v1
kind: Namespace
metadata:
  name: production-apps
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

2. Authoring Hardened Restricted Pod Specifications

Under the Restricted PSS profile, containers must drop all Linux capabilities (DROP ALL), mandate non-root execution (runAsNonRoot: true), disable privilege escalation, and enforce read-only root filesystems.

Explicitly defining non-root user IDs (e.g., runAsUser: 10001) prevents container processes from executing with UID 0 root permissions.

Enforcing readOnlyRootFilesystem prevents attackers from downloading persistent malware payloads into container filesystems.

Mounting emptyDir volumes for transient scratch space maintains read-only root filesystem compliance.

Configuring fsGroup security contexts ensures volume file permissions are managed securely across multi-tenant worker nodes.

Implementing automated continuous monitoring across production nodes ensures that compliance policies remain enforced during infrastructure updates.

Regular security audits should be integrated into DevOps CI/CD pipelines to verify that system configurations conform to zero-trust architecture standards.

Documenting system architecture and access control rules facilitates compliance verification during independent third-party security audits.

Enforcing strict runtime isolation boundaries prevents privilege escalation vectors across multi-tenant cloud environments.

# Compliant Restricted Pod Specification
apiVersion: v1
kind: Pod
metadata:
  name: secure-app-worker
  namespace: production-apps
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    runAsGroup: 10001
    fsGroup: 10001
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: worker
    image: ghcr.io/zyekh/secure-api:v2.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL

3. Testing Enforcement with Audit & Warn Labels

Prior to applying enforce labels in production, use warn and audit labels to identify non-compliant workloads without breaking active deployment pipelines.

Audit logs log non-compliant pod creation events to the Kubernetes API audit stream for review by DevOps security teams.

Using dry-run validation during CI/CD manifest linting prevents non-compliant manifests from reaching cluster API servers.

Staged rollouts using warning annotations allow engineering teams to remediate security manifests proactively.

Implementing automated continuous monitoring across production nodes ensures that compliance policies remain enforced during infrastructure updates.

Regular security audits should be integrated into DevOps CI/CD pipelines to verify that system configurations conform to zero-trust architecture standards.

Documenting system architecture and access control rules facilitates compliance verification during independent third-party security audits.

Enforcing strict runtime isolation boundaries prevents privilege escalation vectors across multi-tenant cloud environments.

# Test namespace compliance with kubectl dry-run
kubectl label --dry-run=server --overwrite namespace default \
  pod-security.kubernetes.io/enforce=restricted

4. Verification & PSS Audit Checklist

Verify that all namespaces possess explicit Pod Security labels and audit API server warning metrics.

Test pod deployment pipelines with non-compliant manifests to verify that admission controllers reject unauthorized specs.

Regularly audit namespace labels to ensure no unauthorized exemptions have been introduced into production clusters.

Automated policy linters prevent un-labeled namespaces from being created in GitOps infrastructure repos.

Implementing automated continuous monitoring across production nodes ensures that compliance policies remain enforced during infrastructure updates.

Regular security audits should be integrated into DevOps CI/CD pipelines to verify that system configurations conform to zero-trust architecture standards.

Documenting system architecture and access control rules facilitates compliance verification during independent third-party security audits.

Enforcing strict runtime isolation boundaries prevents privilege escalation vectors across multi-tenant cloud environments.

# Audit namespace Pod Security labels
kubectl get ns --show-labels | grep "pod-security"

# Test deployment rejection on non-compliant pod
kubectl apply -f non-compliant-pod.yaml

Frequently Asked Questions (FAQ)

Q: What is the difference between Baseline and Restricted PSS?

Baseline prevents known privilege escalations while allowing standard defaults. Restricted enforces read-only filesystems, dropping all capabilities, and non-root UID requirements.

Q: Can PSS labels be overridden by pod authors?

No. PSS labels are defined on Namespaces by cluster administrators, preventing pod authors from bypassing security rules.

Originally published at https://zyekh.com/blog/kubernetes-pod-security-standards-pss-and-admission-control.html