2.16 Kubernetes Cluster Security Architecture

Kubernetes Cluster Security Architecture is the specific layering of independent security mechanisms across the cluster, describing how authentication, authorization, admission control, network policy, and node-level isolation are arranged as successive, non-overlapping layers so that a weakness in any single layer does not by itself compromise the security posture provided by the others.

Defense Organized as Independent Layers

Each Layer Governs a Different Question

The architecture is built around each security layer answering a distinct question: authentication asks who is making a request, authorization asks what that identity may do through the API, admission control asks whether the specific request conforms to policy, network policy asks which Pods may exchange traffic, and node-level isolation asks what a running container process may do to its host.

No Single Layer Is a Complete Solution

Because each layer is architected to address only its own narrow question, none of them alone is sufficient; a correctly authenticated and authorized request can still be rejected by admission control, and a Pod permitted by every API-level control can still be constrained by network policy or by its own security context.

API-Facing Layers

Authentication and Authorization at the Front Door

The first two layers an API request encounters, authentication and authorization, are architected as gatekeepers to the API server itself, determining whether a request is even allowed to proceed before anything about its specific content is examined in depth.

Admission as a Deeper, Content-Aware Check

Admission control is architected as a subsequent, more detailed layer, examining the actual content of an already-authorized request against cluster-specific policy, catching violations that authorization's coarser identity-and-verb model cannot express.

Data-Plane and Runtime Layers

Network Policy Governing Traffic Between Pods

Separately from anything happening at the API layer, network policy is architected to govern which Pods may exchange traffic once they are already running, operating entirely within the data plane rather than through API requests.

Security Contexts Governing Process Privilege

At the innermost layer, security contexts constrain what a container's own operating system process may do once it is executing, independent of any API-level permission the identity that created it may have held.

Why Layered Independence Matters

Containing the Blast Radius of a Single Failure

Because these layers are architected to operate independently, a misconfiguration or compromise affecting one, such as an overly permissive RBAC role, does not automatically grant capabilities governed by another layer, such as unrestricted network access or root-level container privileges.

Layered Security Architecture Diagram