What Is Pod Security Admission? Security Definition
Also known as: Pod Security Admission, Kubernetes pod security, CKS exam pod security, pod security standards, Kubernetes admission controller
On This Page
Quick Definition
Pod Security Admission is a built-in Kubernetes mechanism that checks new pods against a set of security rules before they are allowed to start. It replaces the older Pod Security Policy and helps cluster administrators enforce baseline security without installing extra software. The feature applies three levels of security: privileged, baseline, and restricted. You can configure it using namespaces or labels to control which pods pass or fail based on their configuration.
Must Know for Exams
The Certified Kubernetes Security Specialist (CKS) exam places heavy emphasis on Pod Security Admission because it is the primary mechanism for enforcing pod security in modern Kubernetes clusters. The exam objectives explicitly cover cluster hardening using admission controllers and pod security standards. Candidates must understand how to configure namespace labels for the three modes (enforce, audit, warn) and know the differences between the privileged, baseline, and restricted standards.
Exam questions often present a scenario where a cluster is using the deprecated Pod Security Policy, and the candidate must migrate to Pod Security Admission. This requires knowledge of how to apply labels to existing namespaces and how to use the warn mode to test policies without breaking applications. Another typical question asks which fields are checked by each standard. For example, the baseline standard checks that allowPrivilegeEscalation is false, that privileged containers are not used, and that host namespaces are not shared. The restricted standard additionally requires that containers run as non-root and use a seccomp profile.
The CKS exam also tests the ability to audit cluster compliance using kubectl commands. Candidates may need to run commands to see which namespaces have labels applied, or check which pods violate the current policy. Understanding the difference between enforce and warn modes is critical because choosing the wrong mode can either break production workloads or silently ignore violations. The exam expects candidates to know that the enforce mode blocks pods entirely, while warn mode only shows warnings. Additionally, candidates should be aware that Pod Security Admission only works for pods, not for other Kubernetes resources like Deployments, though the pod spec within Deployments is validated.
Simple Meaning
Think of a building with a security checkpoint at every entrance. Before anyone can enter, they must show their ID badge, and the guard checks whether they are allowed inside based on a set of rules. Pod Security Admission works in a similar way for Kubernetes clusters. When a developer tries to create a pod, Kubernetes automatically checks that pod against a security policy. The policy is not a complicated list of custom rules but uses three standard levels: privileged, baseline, and restricted.
Privileged means no restrictions at all, like allowing anyone into the building without checking. Baseline means basic security is enforced, such as checking that you have a valid ID and not carrying weapons. Restricted means very tight controls, like requiring a background check before entry. Cluster administrators decide which level applies to each namespace, just as a building manager might decide which floors are open to the public and which require special access.
This feature is important because containers often run with more permissions than they need, which can let attackers break out of the container and access the host machine. Pod Security Admission reduces this risk by rejecting pods that try to run as root without a reason, mount sensitive host paths, or use dangerous Linux capabilities. It is a gatekeeper that stops dangerous pods before they run, making the entire cluster safer without requiring developers to learn complex security tools.
Full Technical Definition
Pod Security Admission is a native Kubernetes admission controller that evaluates pods against the Pod Security Standards defined by the Kubernetes project. It was introduced as a stable feature in Kubernetes 1.25 and replaces the deprecated Pod Security Policy (PSP) admission controller. The mechanism operates at the namespace level, where administrators apply a label to each namespace that defines the desired security level. Kubernetes then checks every pod creation request against that level and either admits, warns, or rejects the pod.
The three Pod Security Standards are: privileged, baseline, and restricted. The privileged level allows all known security controls to be disabled, which is intended for system-critical pods that require elevated access. The baseline level enforces the minimum required security restrictions to prevent common privilege escalation attacks, such as disabling host network access, preventing privileged containers, and restricting the use of host PID or IPC namespaces. The restricted level follows the principle of least privilege by disallowing all host-level access, enforcing runtime class selection, and preventing containers from running as root or with unnecessary capabilities.
Implementation is done through namespace labels. The label key is fixed as pod-security.kubernetes.io, and the value includes the enforcement mode and version. For example, a namespace labeled pod-security.kubernetes.io/enforce=baseline will reject any pod that violates baseline standards. The feature supports three modes: enforce, which blocks pods; audit, which logs violations but allows the pod; and warn, which provides a warning to the user but does not block the pod. The warn mode is especially useful during migration from PSP, as it allows developers to see violations without breaking existing workloads.
Under the hood, the admission controller evaluates many pod and container fields: securityContext for runAsUser, runAsGroup, fsGroup, runAsNonRoot, privileged, allowPrivilegeEscalation, seccomp profiles, AppArmor profiles, SELinux options, capability additions, and host namespace sharing. The controller also checks volume types and hostPath usage. If a pod does not meet the standard defined for its namespace, it receives a clear error message explaining which fields violated the policy.
Real-Life Example
Imagine you work in a secure office building that houses multiple companies. Each company rents a separate floor, and each floor has its own access rules. The building has a main security desk at the lobby where everyone entering the building must check in. However, each floor also has its own security guard who enforces that floor's specific rules. Pod Security Admission works like those floor-level security guards combined with a set of building-wide policies.
In this analogy, the entire building is the Kubernetes cluster, and each floor is a namespace. The building management has established three security levels. Level one is the privileged floor, where anyone with a building pass can enter and move freely. This floor might be used for maintenance workers who need to carry tools and access all equipment. Level two is a standard office floor with baseline security. Visitors must show a pass, cannot carry large packages, and cannot enter server rooms. Level three is a restricted floor, such as a research lab, where only pre-approved employees can enter, and they must wear protective gear and follow strict procedures.
When a person arrives at a floor, the floor guard checks the person against the floor's rules. If the person is on the privileged floor, the guard waves them through with no questions. If they are on the baseline floor, the guard checks their badge and verifies they are not carrying anything dangerous. If they try to enter the restricted floor without proper clearance, the guard stops them and explains which rules they violated. This is exactly how Pod Security Admission works. The namespace label tells Kubernetes what level of security to enforce, and the admission controller acts as the guard, checking every new pod and either letting it through, warning the creator, or blocking the pod with a clear explanation.
Why This Term Matters
Pod Security Admission matters because it provides a simple, built-in way to enforce security across a Kubernetes cluster without requiring separate tools or complex configurations. In real IT environments, misconfigured containers are a leading cause of security breaches. Containers that run as root, have unnecessary capabilities, or mount sensitive host directories give attackers a foothold to escape the container and compromise the host. Without pod security controls, a single careless developer can create a pod that opens the entire cluster to attack.
Cluster administrators often manage hundreds of namespaces serving different teams or applications. Pod Security Admission lets them set a baseline security level across all namespaces while allowing exceptions for specific use cases. For example, monitoring tools like node-exporter or network plugins may need privileged access, so they can be placed in a namespace with the privileged level. Meanwhile, regular application pods can be restricted to baseline or restricted levels. This tiered approach balances security with operational requirements.
Another practical benefit is that Pod Security Admission works with Kubernetes native controls, so no additional webhook or sidecar is needed. This reduces complexity and potential points of failure. It also integrates with existing Kubernetes audit logs, making it easy to track violations and adjust policies over time. For organizations that must comply with standards like PCI-DSS or HIPAA, Pod Security Admission helps demonstrate that container workloads are running under least privilege controls. It is not a complete security solution, but it is a critical first line of defense against the most common container misconfigurations.
How It Appears in Exam Questions
In certification exams, Pod Security Admission questions appear in several forms. The most common type is a scenario where a developer reports that a pod fails to start, and the candidate must identify that a security policy is blocking it. For example, a question might describe a Deployment with a container that runs as root in a namespace labeled with pod-security.kubernetes.io/enforce=restricted. The candidate must recognize that the restricted standard forbids running as root, so the pod will be rejected.
Configuration questions are also frequent. These ask the candidate to apply the correct labels to a namespace to enforce a given security standard. For instance, the question might state: A namespace called production must block any pod that violates the baseline standard, but log violations in development namespaces. The candidate must write the correct label values: enforce=baseline for production and audit=baseline for development. They must also know the label key pattern, which includes the version, such as pod-security.kubernetes.io/enforce-version=v1.25.
Troubleshooting questions present a situation where a critical pod is being blocked by security policy, and the candidate must decide how to allow it. The correct approach is often to create a dedicated namespace with a lower security level, rather than modifying the policy for the entire namespace. Another variation asks about migration from Pod Security Policy. The candidate might need to identify that PSP is deprecated in Kubernetes 1.21 and removed in 1.25, and that Pod Security Admission is the replacement.
Architecture questions may ask about the order of admission controllers and how Pod Security Admission interacts with other controllers. For example, a question might test whether the admission controller runs before or after resource validation. The correct answer is that it runs during the admission phase, before the pod is persisted to etcd. Understanding the lifecycle helps candidates reason about when policies are applied.
Study cncf-cks
Test your understanding with exam-style practice questions.
Example Scenario
A company runs a Kubernetes cluster with multiple teams. The platform team wants to enforce that no container runs as root, because a recent security audit found that many pods were running with root privileges, creating a risk. However, the team running the monitoring stack needs one pod to run as root to access hardware metrics. The platform team decides to use Pod Security Admission.
They apply a label to the default namespace: pod-security.kubernetes.io/enforce=restricted. Now any pod created in the default namespace that tries to run as root will be rejected with an error. The monitoring team creates a separate namespace called monitoring-system and labels it with pod-security.kubernetes.io/enforce=privileged. This allows their root-running pod to start normally. The development team, which builds stateless web applications, continues to work in the default namespace and discovers that some of their containers fail to start because they were previously running as root. They update their Dockerfiles to use a non-root user, and the pods start successfully. Within a day, the cluster has zero root containers except for the one legitimate monitoring pod. This scenario shows how Pod Security Admission enables granular security controls without blocking necessary functionality.
Common Mistakes
Thinking Pod Security Admission is the same as Pod Security Policy and can be configured with the same YAML resources.
Pod Security Policy required creating a custom resource definition and binding it to users or service accounts. Pod Security Admission uses simple namespace labels and does not support the same granular controls. The two are entirely different systems.
Understand that Pod Security Admission is configured only via namespace labels, not via policy objects. Forget everything you know about PSP when working with PSA.
Believing that setting enforce=baseline in a namespace will block all pods with any security issue.
Baseline only blocks the most common privilege escalation vectors. It does not enforce things like running as non-root or requiring seccomp profiles. It is possible to create a pod that is insecure but still passes baseline.
Choose the restricted standard if you need strong security controls. Use baseline only for pods that require some flexibility but should still be reasonably safe.
Applying the label without including the version, such as pod-security.kubernetes.io/enforce=baseline without a version suffix.
Without a version, the admission controller defaults to the version of Kubernetes that created the namespace, which may cause unexpected behavior on upgrades. The version label tells Kubernetes which version of the standards to use for validation.
Always include the version label, for example: pod-security.kubernetes.io/enforce-version=v1.25. This ensures consistent behavior across cluster upgrades.
Assuming that Pod Security Admission can block pods based on container image content or vulnerabilities.
Pod Security Admission only checks pod configuration fields like securityContext, capabilities, and host namespaces. It does not scan images for malware, outdated packages, or secrets. It is not a vulnerability scanner.
Use separate tools like container image scanners and admission webhooks to check image content. View Pod Security Admission as a configuration enforcer, not a comprehensive security solution.
Thinking that the audit mode has no effect and can be ignored.
Audit mode logs violations to the audit log, which can be used to detect attacks or identify configuration drift over time. Ignoring audit logs means missing visibility into potential security issues.
Treat audit mode as a monitoring tool. Collect audit logs and review them regularly to identify namespaces where pods are violating the desired standard.
Believing that Pod Security Admission works for all Kubernetes resources, like Deployments or StatefulSets.
The admission controller only checks Pod objects. While a Deployment creates pods, the check happens on the pod, not the Deployment. However, the validation still applies because the pod spec is verified when the pods are created by the controller.
Always check pod-level security settings in your manifests. A Deployment that sets runAsNonRoot in its pod spec will pass the check. Focus on the pod template fields.
Exam Trap — Don't Get Fooled
A question asks: 'You have a namespace labeled with pod-security.kubernetes.io/enforce=restricted. You create a pod with securityContext.runAsUser: 1000. Will the pod be allowed?' The trap is that many learners answer 'no' because they think restricted requires runAsNonRoot, but the question tests if runAsUser 1000 is acceptable under restricted.
Memorize the exact fields required by each standard. For restricted, runAsNonRoot must be explicitly set to true. A user ID of 1000 is not enough. Also, learn the difference between user ID and the runAsNonRoot flag.
Always check the explicit flag in the exam scenario.
Commonly Confused With
Pod Security Policy was the original Kubernetes mechanism for enforcing pod security, but it was deprecated and removed. It required creating API objects and binding them to service accounts. Pod Security Admission uses namespace labels instead and is much simpler. PSP was complex and easy to misconfigure, while PSA is streamlined and built-in.
With PSP, you would create a YAML file defining allowed capabilities and then create a RoleBinding. With PSA, you just add a label like 'pod-security.kubernetes.io/enforce=baseline' to the namespace.
OPA Gatekeeper is a more powerful, general-purpose admission controller that uses custom policies written in Rego. It can enforce any rule, not just pod security standards. Pod Security Admission is limited to the three standard levels and cannot be customized. Gatekeeper is better for complex, organization-specific policies, while PSA is simpler for standard security rules.
If you need to allow pods only from a specific container registry, that requires OPA Gatekeeper. If you just want to prevent privileged containers, PSA does the job.
Container Security Context is a set of fields in the pod spec that define privileges for a single container, like 'privileged: true' or 'runAsUser: 1000'. Pod Security Admission is a separate admission controller that checks those fields against policies. The security context is what you configure; the admission controller is what validates it.
You set 'privileged: false' in the container's securityContext. Pod Security Admission checks that value against the namespace policy and rejects the pod if the policy requires it to be false.
Admission controller is a general category of Kubernetes components that intercept requests before they are persisted. Pod Security Admission is one specific type of admission controller. There are many others, like NamespaceLifecycle or ResourceQuota. The term 'admission controller' is the parent concept, while Pod Security Admission is a child implementation.
Think of admission controllers as security guards at different checkpoints. Pod Security Admission is the guard that checks the pod's security settings. Other guards check quotas or namespaces.
Step-by-Step Breakdown
Namespace Label Configuration
An administrator chooses a security level (privileged, baseline, or restricted) and a Kubernetes version, then applies the label to a namespace. For example, the label 'pod-security.kubernetes.io/enforce=baseline' tells the admission controller to block pods that violate baseline standards. The version label is also added to ensure consistent validation rules.
Pod Creation Request
A user or automated tool submits a request to create a pod using kubectl, an API call, or a controller like a Deployment. This request includes the entire pod spec with securityContext, containers, volumes, and other fields. The request is sent to the Kubernetes API server.
Mutating Admission Phase
Before validation, mutating admission controllers may modify the request. For Pod Security Admission, there is no mutation step, but other controllers can add labels or defaults. This step runs first to set any missing values.
Validating Admission Phase
Pod Security Admission runs as a validating admission controller. It reads the namespace label and compares the pod spec against the chosen standard. It checks specific fields: privileged, allowPrivilegeEscalation, hostPID, hostIPC, hostNetwork, runAsNonRoot, capabilities, seccomp profiles, and more. If the pod violates the standard, the controller issues a rejection or warning depending on the mode.
Response to User
If the pod passes validation, the admission controller allows the request to proceed to etcd for storage. If it fails, the API server returns an error message specifying which fields caused the violation. For warn mode, the pod is still created, but a warning is printed to the user. For audit mode, the violation is logged silently.
Pod Execution on Node
After admission, the scheduler assigns the pod to a node, and the kubelet creates the containers. The security settings in the pod spec are applied at runtime by the container runtime. If a field was allowed during admission, it will be used as configured.
Audit Log Review
Administrators configure audit logging to capture all admission decisions. They can review logs to see which pods were warned or blocked, then adjust policies or fix the offending pods. This feedback loop helps maintain security over time.
Practical Mini-Lesson
To implement Pod Security Admission in your own cluster, start by understanding your environment. If you are using Kubernetes 1.25 or later, the feature is enabled by default. You can verify this by checking the API server flags or by looking for the built-in admission controller list. The command 'kubectl get podsecurityadmissionconfiguration' may not exist because it is not a resource. Instead, you configure it through namespace labels.
The first step is to choose a namespace to enforce. It is best to start with a non-production namespace. Apply the warn mode first to see what violations exist without breaking anything. For example, run 'kubectl label namespace my-namespace pod-security.kubernetes.io/warn=restricted'. This will show a warning when you create a pod that violates restricted standards, but the pod will still run. Review the warnings and fix the pod specs.
Once you are confident that your pods can meet the standard, switch to enforce mode. Label the namespace with 'pod-security.kubernetes.io/enforce=restricted'. Now any pod that violates the standard will be rejected. You will see errors like 'admission webhook validation failed: pod violates PodSecurity'. The error message tells you exactly which fields caused the issue. Fix the pod spec and reapply.
If you have pods that need elevated privileges, create a separate namespace with a lower security level. For example, label a namespace 'kube-system' and 'monitoring' with 'privileged' if they require host access. Be careful not to use privileged level for regular workloads. Always use the highest level that works for your application.
To audit existing namespaces, you can run 'kubectl label namespace --all pod-security.kubernetes.io/audit=restricted'. This will log all violations without affecting operations. Then check the Kubernetes audit logs to find problematic pods. You can also use tools like 'kubesec' or 'kube-bench' to scan for misconfigurations, but Pod Security Admission provides real-time enforcement.
A common pitfall is forgetting to add the version label. Without it, the controller uses the version from the namespace's creation metadata, which might be outdated. Always set both the enforce and enforce-version labels, like: 'pod-security.kubernetes.io/enforce=restricted' and 'pod-security.kubernetes.io/enforce-version=v1.30'. This ensures that after a cluster upgrade, the policy behaves as expected.
Finally, test your configuration by creating a simple pod that violates the policy. Use a one-liner like 'kubectl run test-pod --image=nginx --restart=Never --privileged'. If the namespace is set to restricted, you should see an error immediately. If not, check the labels. This hands-on trial is invaluable for understanding how the feature behaves before you apply it to production.
Memory Tip
Think 'Pods go through PSA three modes: Enforce blocks, Audit logs, Warn shows.' For the three standards, remember 'Privileged allows everything, Baseline blocks common dangers, Restricted blocks almost everything.' The exam often asks whether a pod with a specific setting passes a given standard.
Covered in These Exams
Related Glossary Terms
802.1X is a network access control standard that authenticates devices before they are allowed to connect to a wired or wireless network.
Two-factor authentication (2FA) is a security method that requires two different types of proof before granting access to an account or system.
5G is the fifth generation of cellular network technology, designed to deliver faster speeds, lower latency, and support for many more connected devices than previous generations.
Frequently Asked Questions
What is the difference between Pod Security Admission and Pod Security Policy?
Pod Security Policy is an older feature that was deprecated in Kubernetes 1.21 and removed in 1.25. It required complex API objects and role bindings. Pod Security Admission is its replacement, using simple namespace labels and three built-in standards. It is much easier to configure and maintain.
Do I need to install anything to use Pod Security Admission?
No, Pod Security Admission is built into the Kubernetes API server. You do not need to install any additional software. It is enabled by default in Kubernetes 1.25 and later. You just need to apply the appropriate labels to your namespaces.
Can Pod Security Admission block pods based on the container image used?
No, it only checks the pod configuration fields like securityContext, capabilities, and host namespace usage. It does not inspect the container image contents. To block images with vulnerabilities, you need a separate tool like an image scanner or an admission webhook such as OPA Gatekeeper.
What happens if I apply a namespace label after pods are already running?
Existing pods are not affected by the label. Only new pod creation requests are checked. This is why it is safe to apply the aud or warn mode first, to see what violations exist without disrupting running workloads.
Which Kubernetes versions support Pod Security Admission?
Pod Security Admission was introduced as a beta feature in Kubernetes 1.22 and became stable in 1.25. If you are using a version older than 1.22, you will need to use Pod Security Policy instead, but you should upgrade as soon as possible since PSP is removed.
Can I create custom security standards beyond privileged, baseline, and restricted?
No, Pod Security Admission only supports the three predefined standards. If you need custom policies, you must use a different admission controller like OPA Gatekeeper or a custom webhook. However, the three standards cover the majority of common security requirements.
Does Pod Security Admission work with Kubernetes distributions like OpenShift or Rancher?
Yes, it works with any Kubernetes distribution that uses the standard API server, including OpenShift, Rancher, EKS, AKS, GKE, and others. However, some distributions may add their own admission controllers or custom policies. Always check the vendor documentation for any differences.
Summary
Pod Security Admission is a critical Kubernetes security feature that every CKS candidate must master. It replaces the older Pod Security Policy and provides a simple, label-based mechanism to enforce three levels of security on pods: privileged for unrestricted access, baseline for common safety rules, and restricted for strict least privilege. The feature operates as a validating admission controller, checking new pod creation requests against the standard defined for the namespace. It supports enforce, warn, and audit modes to help administrators adopt security gradually without breaking existing workloads.
In the CKS exam, you will face questions about configuring namespace labels, understanding which pod fields are checked by each standard, and migrating from PSP. Practical skills include applying labels with the proper version suffix, using warn mode to test policies, and creating separate namespaces for privileged workloads. Common mistakes include confusing PSA with PSP, forgetting the version label, and assuming it checks image contents. Remember that PSA is a configuration validator, not a vulnerability scanner. By mastering Pod Security Admission, you demonstrate the ability to harden a Kubernetes cluster against the most common container misconfigurations and privilege escalation attacks.