A Pod Security admission exemption skips enforce, audit and warn for matching requests. Keep exemptions few, name specific namespaces or runtime classes, and avoid exempting controller service accounts, which would silently exempt every user who can create the matching workload.
What an exemption does
The docs say exempt requests are ignored entirely: enforce, audit and warn are all skipped. Exemptions must be listed explicitly, and they come in three kinds:
- Usernames, either authenticated or impersonated.
- RuntimeClassNames, for pods or workload resources that specify an exempt runtime class.
- Namespaces, for pods or workload resources in an exempt namespace.
The controller trap
Most pods are created by controllers, not by people. The docs warn that exempting an end user covers only direct pod creation. They also say controller service accounts such as the replicaset controller's account generally should not be exempted, because doing so would implicitly exempt any user who can create the corresponding workload.
Example: if you exempt the account that creates pods for ReplicaSets, then anyone who can create a Deployment can get a pod that skips the check.
Namespace exemptions
Exempting a namespace is common for system components that need host access. It is also the largest hole, since every pod there passes. If you must, keep the exempt namespace small, restrict who can create workloads in it, and add other controls. The RBAC good practices page advises treating boundaries within a namespace as weak.
Remember also that namespace labels drive the policy, and permission to patch Namespaces can change them. See who can weaken your admission controls.
Updates that are exempt anyway
The docs list some updates that skip checks when they change only certain fields: metadata other than seccomp or AppArmor annotations, valid updates to activeDeadlineSeconds, and valid updates to tolerations. These are narrow and sensible, but know that they exist.
How to review your list
- Print the current exemptions from your admission configuration.
- For each entry, write the reason, the owner and a review date.
- Check whether the exempt thing still exists.
- Try to replace namespace exemptions with a more permissive level on one namespace. A baseline label on a single namespace is more visible than a hidden exemption.
What exemptions do not replace
Exempting is not the same as meeting the standard. If a workload cannot meet the Restricted level, put it in its own namespace with a looser label and the reason recorded. Our post on Pod Security Standards baseline vs restricted explains the levels.
Safeguard's policies and gates can check manifests before they reach the cluster, and compliance evidence automation can hold the exemption review. It does not enforce Pod Security in the cluster.
Quick check
Should I exempt the ReplicaSet controller account to fix a failing rollout?
No. The docs say controller accounts generally should not be exempted, since that exempts every user who can create the matching workload.
Sources
Last reviewed: 19 October 2026.
