PodSecurity violation: The pod does not meet the security standard enforced on its namespace

Pod Security Admission rejects pods that violate the standard a namespace is labelled with. The message lists every violated rule at once, which makes it unusually efficient to fix.

Applies to: Kubernetes 1.23 and later

What it means

Pod Security Admission enforces the Pod Security Standards — privileged, baseline, and restricted — according to labels on the namespace. Each namespace can independently enforce, audit, or warn at a given level. A rejection names every rule the pod broke, for example violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfile. The restricted level is strict enough that most images written before it need several explicit fields added, and the list format means all of them can be addressed in one pass rather than one rejection at a time.

Most common causes

• The namespace enforces restricted and the pod does not set runAsNonRoot: true.
• allowPrivilegeEscalation is not explicitly set to false — omitting it is a violation, since the default is permissive.
• Capabilities are not dropped. restricted requires dropping ALL.
• No seccompProfile is set to RuntimeDefault or Localhost.
• A hostPath volume, host networking, or a host port under baseline or above.
• A privileged container, which is forbidden at every level except privileged.
• A namespace inheriting a cluster-wide default that was not expected.

How to diagnose it

1. Read the whole message — every violated rule is listed, so there is no need to iterate.
2. Check the namespace's labels: kubectl get ns NAMESPACE --show-labels and look for pod-security.kubernetes.io/*.
3. Test a manifest against a level before applying it by using the warn label on a scratch namespace.
4. Check whether the enforcement is new — a namespace label added recently will start rejecting workloads that have run for months.
5. For workloads installed from a chart, check whether it offers security context values rather than editing rendered output.

How to fix it

1. Set the fields the standard requires: runAsNonRoot: true, allowPrivilegeEscalation: false, capabilities.drop: ["ALL"], and seccompProfile.type: RuntimeDefault.
2. Build images that run as a non-root user, since runAsNonRoot requires the image to specify a numeric user or the pod to set runAsUser.
3. Replace hostPath volumes with a supported volume type.
4. If a workload genuinely requires elevated access — a CNI agent, a node monitoring tool — place it in a namespace labelled privileged rather than lowering the level everywhere.
5. Roll out enforcement using the warn and audit labels first, so violations are visible before they become rejections.

Notes

Pod Security Admission applies at the namespace level and cannot be scoped to individual workloads. A single pod that needs elevated privileges therefore forces a decision about the whole namespace, which is a strong argument for isolating such workloads in their own.

Related

• admission webhook denied the request — An admission webhook rejected the object
• Error from server (Forbidden) — RBAC denied the request

Sources

• Kubernetes documentation — Pod Security Admission
• Kubernetes documentation — Pod Security Standards
• Kubernetes documentation — Configure a Security Context for a Pod or Container