Kubernetes Security Fundamentals
Last reviewed: — verified against Kubernetes 1.36.
Kubernetes is a powerful container orchestration platform, but its security model is layered and explicit. This page is the head reference for the foundational concepts every operator and developer needs before reading the attack vector or best practices sections — the shared responsibility split, the 4C model, the API request lifecycle (authentication → authorization → admission), and the security mindset that ties them together.
Why Fundamentals Matter
Without a clear mental model of how the API server processes a request, hardening efforts tend to focus on the wrong layer. Most production incidents in Kubernetes trace back to a few foundational gaps: an over-broad ClusterRoleBinding, an authentication mode that was never disabled, or a workload that bypassed admission because the policy engine was misconfigured. The articles in this section build that mental model in the order the API server itself uses to evaluate every call.
Once those primitives are clear, the attack vectors and mitigations on the rest of the site become specific applications of the same patterns rather than disconnected recipes.
The Shared Responsibility Model
Kubernetes security follows a shared responsibility model, where different stakeholders are responsible for securing distinct layers of the system:
| Layer | Owner | Examples |
|---|---|---|
| Cloud / data centre | Cloud provider or platform team | Hypervisor, hardware, IAM control plane |
| Cluster control plane | Cluster operator | API server flags, etcd encryption, audit logs |
| Cluster workloads | Operator + developer | NetworkPolicy, RBAC bindings, admission policy |
| Container image | Developer + supply-chain owner | Base image, dependencies, build provenance |
| Application code | Developer | Auth, input validation, secret usage |
Security is not a single team's responsibility — it requires explicit hand-offs across these layers. Treat each row as a separate change-management surface with its own controls and audit trail.
The Kubernetes API Request Lifecycle
Every authenticated call to the API server passes through three phases. Most fundamentals questions reduce to "which phase is this?".
| Phase | Purpose | Failure Mode | Reference |
|---|---|---|---|
| Authentication | Establish "who is the caller?" | Anonymous or impersonation accepted in error | Authentication Methods |
| Authorization | Decide "is this caller allowed to do this?" | Over-broad RBAC or wildcard verbs | Authorization Methods |
| Admission | Validate or mutate the object before persistence | Webhook bypass, missing policy | Compromised API Server Mitigation |
Knowing which phase a control belongs to prevents whole classes of mistakes — for example, RBAC cannot enforce "image signed by Cosign", because that is an admission-time concern, not authorization.
Topics Covered in This Section
Understanding Kubernetes Attack Surfaces
A walkthrough of every layer an attacker can reach in a Kubernetes cluster — from the cloud control plane down to the application — and the controls that bound each one.
The Four C's of Cloud Native Security
The Code → Container → Cluster → Cloud layered model. Use it as a checklist when reviewing a new platform or onboarding a workload.
Authentication and Access Control
The authentication strategies the API server supports — client certificates, ServiceAccount tokens, OIDC, webhook authenticators — and how to pick between them.
Authorization
RBAC, ABAC, Node authorizer, Webhook, and the order in which the API server evaluates them. Includes guidance on least privilege and how to audit existing bindings.
Authentication Modes Compared
Kubernetes supports multiple authentication strategies that can be combined on the same API server. The right choice depends on who needs access and how identity is provisioned outside the cluster.
| Mode | Identity Source | Rotation Story | Best Fit | Notes |
|---|---|---|---|---|
| Client certificates | Cluster CA | Manual certificate rotation; revocation is hard | Bootstrapping admins, kubelets | Avoid for end users — no central revocation |
| ServiceAccount tokens | API server (projected) | Bound tokens with audience and expiration (default) | In-cluster workloads | Disable automountServiceAccountToken when not needed |
| OIDC | External IdP (Okta, Azure AD, Google) | IdP-managed; revocation via IdP | Human users at scale | Group claims map naturally to RBAC subjects |
| Webhook token | External service called by API server | Webhook decides | Bespoke identity systems | Latency adds to every API call |
| Static tokens / passwords | File on disk | None | Never in production | Removed in 1.19 (basic auth); avoid token files too |
Read more: Authentication Methods · ServiceAccounts
Authorization Modes Compared
The API server evaluates authorizers in the order configured by --authorization-mode. The first authorizer that returns "allow" or "deny" wins; otherwise the request falls through to the next.
| Mode | Policy Source | Granularity | Best Fit |
|---|---|---|---|
| RBAC | Role / ClusterRole resources | Verb × resource × namespace | Default for almost every cluster |
| ABAC | JSON policy file on the API server | Arbitrary attributes | Legacy clusters; static policy |
| Node authorizer | Built-in, identifies kubelets via group | Limited to kubelet API surface | Always-on for kubelet identity |
| Webhook | External SubjectAccessReview service | Arbitrary attributes via webhook | Centralised policy engines outside the cluster |
Read more: Authorization Methods · RBAC · ABAC · Node Authorizer · Webhook Authorization
Try It: Live YAML Security Analyzer
Many of the fundamentals on this page show up as concrete fields in a manifest — automountServiceAccountToken, serviceAccountName, securityContext, and the verbs of a Role. Paste a manifest below to see how it scores against those primitives before you apply it.
Version-Specific Notes (Kubernetes 1.36)
The fundamentals layer has stabilised in recent Kubernetes versions. The defaults below should be assumed for any new cluster:
- Bound ServiceAccount tokens — Default. Tokens projected into pods carry an audience and a short expiration; the legacy long-lived token Secret pattern is deprecated.
- Anonymous authentication restriction — Beta in 1.31, GA in 1.33. The
--anonymous-auth-configflag scopes anonymous requests to specific paths instead of the all-or-nothing legacy behaviour. - Structured authentication and authorization configuration —
AuthenticationConfigurationandAuthorizationConfigurationfiles (replacing--authentication-token-webhook-*flag flurry) are GA in 1.30+, simplifying multi-OIDC and conditional webhook setups. - Validating Admission Policy — GA since 1.30. CEL-based admission policies live in the API server and remove the need to run a webhook for many admission rules.
Removed APIs to remember:
- Static password file (
--basic-auth-file) — Removed in 1.19. Never in any supported cluster. - Token file (
--token-auth-file) — Still present but actively discouraged; treat as legacy.
Always check the Kubernetes deprecation guide before upgrading.
Security Mindset in Kubernetes
Three principles tie the fundamentals together. Apply them as defaults on any new cluster.
Zero Trust
Every request — from a human, a workload, or a control-plane component — must be authenticated and authorized. Default-deny policies should apply to network traffic and to ServiceAccount tokens (automountServiceAccountToken: false unless required).
Least Privilege
Workloads, users, and ServiceAccounts get the minimum permissions required. Avoid wildcard verbs and resources in RBAC. Drop all Linux capabilities and re-add only what the application needs.
Defense in Depth
Layer authentication, authorization, admission control, network policy, and runtime detection. Any single misconfiguration should be contained by the next layer rather than leading directly to compromise.
Conclusion
Kubernetes security is best understood as a sequence: who is the caller (authentication), what are they allowed to do (authorization), and is the resulting object safe to admit (admission). Master those three primitives and the rest of the site — attack vectors, best practices, tooling — becomes a set of applications of the same model rather than a list of unrelated rules.