In February 2022, security researchers demonstrated CVE-2022-0185—a container escape vulnerability affecting Linux kernels. An attacker with access to a container running as root could exploit a heap overflow in the filesystem context API to escape the container entirely and gain root access to the host node. A single compromised pod became a compromised cluster.
Container escapes exploit a fundamental problem: containers running with excessive privileges. Root users inside containers, mounted host filesystems, elevated Linux capabilities—each creates attack surface. Kubernetes Pod Security Standards (PSS) exist to eliminate these vectors systematically, enforcing security constraints before pods ever start.
Your Task API currently runs with default security settings. This lesson transforms it into a hardened workload that passes the most restrictive PSS profile.
Pod Security Standards define three progressively restrictive security profiles. Kubernetes enforces these profiles through the Pod Security Admission controller—a built-in admission controller enabled by default since Kubernetes 1.25.
When to use each level:
Your Task API belongs in the Restricted profile. It processes user requests, stores data, and has no legitimate need for host access or elevated privileges.
PSS namespace labels support three enforcement modes, allowing gradual rollout:
Best practice: Apply all three modes simultaneously. This provides immediate enforcement while also generating warnings and audit logs for operational visibility.
The Task API namespace needs Restricted profile enforcement. Apply labels using kubectl:
Output:
Verify the labels are applied:
Output:
What these labels mean:
With enforcement active, attempt to deploy a privileged container. Create test-privileged.yaml:
Apply the test pod:
Output:
The admission controller rejected the pod before it could be created. This is PSS working correctly.
The Restricted profile requires specific securityContext fields. Here is a compliant Task API deployment. Create task-api-deployment.yaml:
Output:
Output:
Verify pods are running:
Output:
Each securityContext field addresses a specific attack vector:
Why the /tmp volume mount?
With readOnlyRootFilesystem: true, your application cannot write anywhere in the container filesystem. Many applications need a writable directory for temporary files, caches, or logs. The emptyDir volume provides a writable /tmp that:
When migrating existing workloads to Restricted profile, you will encounter these violations:
Given this failing deployment:
The fix requires adding complete security context:
Use dry-run mode to test compliance without creating resources:
Output (compliant):
Output (non-compliant):
The --dry-run=server flag sends the request through admission control but does not persist the resource. This validates PSS compliance before deployment.
Different environments warrant different PSS levels:
Create namespace with appropriate labels during provisioning:
Notice the development namespace uses enforce=baseline but warn=restricted. Developers see Restricted violations as warnings, preparing them for production constraints without blocking their work.
Test your cloud-security skill against what you learned:
Evaluation questions:
If any answers are "no," update your skill with the patterns from this lesson.
Test your understanding of Pod Security Standards and secure container configuration.
Prompt 1:
What you're learning: How to audit existing configurations for PSS compliance. The violations include: runAsUser: 0 (root), allowPrivilegeEscalation: true (must be false), and adding capabilities instead of dropping ALL. Practice identifying each violation before the fix.
Prompt 2:
What you're learning: The difference between Kubernetes configuration and container image defaults. The nginx:latest image runs as root by default—setting runAsNonRoot: true tells Kubernetes to reject containers that would run as root, but doesn't change the image. The fix requires either using an nginx image built for non-root (nginx:1.25-alpine with explicit USER) or specifying runAsUser that overrides the image default.
Prompt 3:
What you're learning: How to design a progressive enforcement strategy across environments. The pattern uses Privileged for dev (maximum flexibility), Restricted with warn for pre-prod (visibility without blocking), and Restricted with enforce for production (zero tolerance).
Pod Security Standards are admission-time controls—they prevent non-compliant pods from being created but do not affect already-running pods. After enabling PSS on a namespace, existing non-compliant pods continue running until they are deleted or restarted. Use kubectl rollout restart to force re-evaluation of existing deployments against PSS policies.