How do Kubernetes NetworkPolicies, RBAC, and Pod Security Standards work together for defense in depth?

Think of securing a building. RBAC is the badge system that controls who can enter which floors and rooms (API permissions). Pod Security Standards are the building codes that prevent tenants from doing dangerous things like removing fire exits or storing explosives (runtime restrictions). NetworkPolicies are the internal walls and locked corridors that prevent someone on one floor from accessing another floor without authorization (network segmentation). Each layer addresses a different attack vector, and all three are needed for comprehensive security.

RBAC (Role-Based Access Control) governs who can interact with the Kubernetes API and what operations they can perform. A Role defines permissions (verbs like get, list, create, delete on resources like pods, secrets, deployments) within a namespace. A ClusterRole defines permissions cluster-wide. RoleBindings and ClusterRoleBindings associate roles with users, groups, or service accounts. Without RBAC, a compromised service account could read Secrets from other namespaces, create privileged pods, or delete critical workloads. Properly scoped RBAC ensures the payments-api ServiceAccount can only read its own ConfigMaps and Secrets, not those belonging to other teams.

Pod Security Standards (the replacement for the deprecated PodSecurityPolicy) define three levels: Privileged (unrestricted), Baseline (prevents known privilege escalations), and Restricted (heavily hardened). These are enforced through the Pod Security Admission controller using namespace labels. Restricted mode prevents running as root, using host networking, mounting hostPath volumes, adding Linux capabilities, and running privileged containers. This matters because a container escape from a privileged pod gives full root access to the host node, which compromises all pods on that node and potentially the entire cluster.

NetworkPolicies, as the third layer, restrict which pods can communicate with which other pods and external systems. Even if an attacker compromises a pod, NetworkPolicies prevent lateral movement to the database, secrets store, or other microservices. Combined with RBAC preventing the compromised pod's ServiceAccount from reading other Secrets, and Pod Security preventing privilege escalation to the host, the blast radius of a single compromised container is contained to that container's existing data and network connections.

In production, these three controls must be deployed together because each has blind spots. RBAC alone cannot prevent a pod from connecting to a database it should not access (that is a network concern). NetworkPolicies alone cannot prevent a pod from running as root and escaping to the host. Pod Security alone cannot prevent a compromised pod from calling the Kubernetes API to read secrets. Defense in depth means that bypassing one control does not grant full access.

The non-obvious gotcha is that Pod Security Admission only warns or denies at pod creation time — it does not retroactively affect running pods. If you add Restricted enforcement to a namespace with existing non-compliant pods, those pods continue running until they are recreated. Another common gap is that RBAC for ServiceAccounts often starts too permissive (using default ServiceAccount with broad permissions) and is never tightened. Teams should create dedicated ServiceAccounts per workload with minimal permissions and disable token automounting for pods that do not need API access.