Pod Security Admission (PSA) is the built-in mechanism in Kubernetes for enforcing security restrictions on Pods, serving as the replacement for the deprecated PodSecurityPolicy. It operates as an admission controller that validates Pod requests against predefined Pod Security Standards (PSS) befor…Pod Security Admission (PSA) is the built-in mechanism in Kubernetes for enforcing security restrictions on Pods, serving as the replacement for the deprecated PodSecurityPolicy. It operates as an admission controller that validates Pod requests against predefined Pod Security Standards (PSS) before they are scheduled.
The PSS defines three cumulative policy levels:
1. **Privileged**: Unrestricted and open, intended for system-wide infrastructure workloads like storage drivers or CNI plugins.
2. **Baseline**: Minimally restrictive, preventing known privilege escalations while supporting most common container configurations.
3. **Restricted**: The most secure level, enforcing strict hardening best practices, such as requiring non-root users and dropping Linux capabilities.
PSA applies these standards using three specific modes:
- **Enforce**: Rejects the Pod creation if it violates the standard.
- **Audit**: Allows the Pod but records a violation in the cluster audit logs.
- **Warn**: Allows the Pod but displays a warning message to the client.
In the context of the CKA exam, configuration is primarily handled via Namespace labels. For example, applying the label `pod-security.kubernetes.io/enforce: restricted` to a namespace ensures that only Pods complying with the Restricted profile can run there. If a user attempts to deploy a Pod without the necessary `securityContext` settings (e.g., `runAsNonRoot: true`), the admission controller will reject the request. While granular exemptions can be configured via the API server's AdmissionConfiguration file, understanding how to apply namespace labels and remediate Pod manifests to satisfy these standards is critical for Cluster Architecture security.
Pod Security Admission and Standards
Why is it Important? With the deprecation and removal of PodSecurityPolicy (PSP), Pod Security Admission (PSA) has become the primary, built-in mechanism for securing Kubernetes workloads in the CKA exam. It allows administrators to enforce security standards at the Namespace level without requiring external controllers like OPA/Gatekeeper. Understanding this is crucial for the 'Workloads & Scheduling' and 'Security' domains.
What is it? Pod Security Admission is an admission controller enabled by default. It evaluates Pod specifications against a set of Pod Security Standards before they are allowed to run. These standards define three levels of security policies: 1. Privileged: Unrestricted (allows everything). 2. Baseline: Minimally restrictive (prevents known privilege escalations). 3. Restricted: Highly restrictive (follows current hardening best practices, e.g., no root, no hostPath).
How it Works PSA is controlled entirely through Namespace Labels. When a Pod is created, the admission controller checks the labels on the Namespace to determine which Standard (Privileged, Baseline, Restricted) to apply and which Mode to use.
The Three Modes: 1. enforce: The creation of the Pod is rejected if it violates the policy. 2. audit: The Pod is allowed, but the violation is recorded in the audit logs. 3. warn: The Pod is allowed, but a warning message is displayed to the user.
How to Configure (The Syntax): To apply a policy, you simply label the namespace: pod-security.kubernetes.io/<MODE>=<LEVEL>
Exam Tips: Answering Questions on Pod Security Admission 1. Memorize the Label Format: You will not edit a config file; you will run a kubectl command. For example, to enforce the restricted standard on namespace 'dev': kubectl label ns dev pod-security.kubernetes.io/enforce=restricted
2. Watch the Requirement Verbs: If the question asks to stop or prevent insecure pods, use the enforce mode. If the question asks to identify or log issues without stopping workloads, use the audit or warn mode.
3. Checking Configuration: If you need to check why a Pod is failing or verify your work, run: kubectl get ns --show-labels Look for the pod-security.kubernetes.io labels.
4. Handling Versions: While rare, if an exam question specifies a Kubernetes version for the policy, add the version label: pod-security.kubernetes.io/enforce-version=v1.29