Why Security Is a Layered Problem
Think of securing a bank. There's the physical building (walls, locks), the vault room (access cards), the vault itself (combination lock), and the teller's procedures (who can authorize a withdrawal). Breaching one layer doesn't mean you've breached all of them. Kubernetes security works the same way — multiple independent layers, each with a distinct responsibility.
This layered model is formally called the 4C's of Cloud Native Security:
- Cloud: The physical or virtual infrastructure — AWS, Azure, GCP, or bare metal. This includes network firewalls, IAM roles for nodes, and disk encryption.
- Cluster: The Kubernetes API server, RBAC, admission controllers, and component configuration. This is our focus today.
- Container: Image scanning, image signing, and runtime restrictions (e.g., seccomp profiles, AppArmor).
- Code: Your application logic — SQL injection prevention, dependency vulnerability scanning, secrets management in code.
The Three Questions Every Cluster Must Answer
Within the Cluster layer, every request to the Kubernetes API server passes through a sequential security pipeline. The pipeline answers three questions in order:
- Who are you? — Authentication (AuthN). Verify the identity of the caller.
- What are you allowed to do? — Authorization (AuthZ). Check permissions against RBAC rules.
- Is your workload safe to run? — Admission Control. Validate and mutate the resource before it's persisted.
A request must pass all three gates. Failing any one of them stops the request dead. Understanding these three gates — and how they interact — is the foundation of Kubernetes security.