Pod Security Admission has been stable since Kubernetes 1.25; pair it with NetworkPolicy to block risky pods and lateral traffic safely. Read now.
Why PSA and Network Policies belong together
Pod Security Admission (PSA) has been stable since Kubernetes 1.25. It evaluates pods against a defined security posture before they are admitted to the cluster. That stops many risky configurations at the gate: privileged containers, host path mounts, host networking, and other settings that expand the attack surface of a single workload.
PSA alone does not control how pods talk to each other after they run. NetworkPolicy fills that gap. It constrains which pods may send or receive traffic, so a compromised or misconfigured workload has a smaller path for lateral movement. Used together, one layer limits what a pod can be, and the other limits what it can reach.
Applying Pod Security Admission without breaking workloads
PSA is typically enforced per namespace through labels that select a mode and a profile. Modes range from audit and warn to enforce. Profiles define how strict the rules are, from baseline expectations most workloads can meet to restricted rules that demand stronger isolation. Start with audit or warn in namespaces that already host production traffic so you can see violations before you block them.
Move to enforce only after you have fixed or exempted legitimate exceptions. Prefer fixing the pod template over carving permanent holes: drop unnecessary capabilities, run as non-root when the image allows it, and avoid host namespaces unless the workload truly needs them. Keep privileged and host-path use in a small set of namespaces that you treat as high trust, and leave application namespaces on a stricter profile.
Writing NetworkPolicies that match real traffic
A default-deny posture is the practical starting point for sensitive namespaces. Deny all ingress and egress first, then open only the paths the application needs: from the ingress controller or service mesh to the app pods, from the app to its database, and outbound DNS or external APIs when required. Label pods consistently so selectors stay stable when you roll out new versions.
- Scope policies by namespace and pod labels, not by IP addresses that change on every restart.
- Separate ingress rules (who may call this service) from egress rules (what this service may call).
- Allow DNS explicitly if you deny egress by default, or name resolution will fail in ways that look like application bugs.
- Review policies when you add a new dependency; a missing allow rule is safer than an open default, but it will surface as timeouts in testing.
NetworkPolicy only works if the cluster’s network plugin implements it. Confirm that your CNI supports the features you rely on before you treat policy as a security control. Without enforcement in the data plane, the objects are documentation, not protection.
Operational habits that keep both controls effective
Treat PSA and NetworkPolicy as part of the same change process. When a team requests a new capability or an open port, require a short justification and a time-bound review. Encode the intended posture in namespace labels and policy manifests so it travels with the environment definition rather than living only in a runbook.
Watch for drift: a pod that passes admission but then needs an emergency privilege bump, or a policy that was loosened “just for debugging” and never restored. Periodic reviews of enforce-mode namespaces and of any policy that allows broad selectors help catch that. The goal is not perfect lockdown on day one. It is a clear baseline for what pods may do, plus network paths that match only the traffic you intend to allow.