23 Kubernetes Security Identity and Access
Kubernetes Security Identity and Access manages access control and identity in container environments through policies and authentication.
Kubernetes Security Identity and Access is the layered set of mechanisms Kubernetes uses to determine who or what is making a request to the cluster, and what that identity is permitted to do, governing every interaction with the API server from human operators to workloads running inside the cluster itself.
Authentication
Identifying the Requester
Authentication establishes who is making a request to the API server. Kubernetes does not manage user accounts itself; instead, it delegates identity verification to external mechanisms such as client certificates, bearer tokens, or integration with an external identity provider through OpenID Connect.
Service Accounts
For workloads running inside the cluster, Kubernetes provides a built-in identity type called a service account, which Pods use to authenticate to the API server, typically presenting a token that is automatically mounted into the Pod's filesystem.
Authorization
Deciding What Is Allowed
Once a request's identity is established, authorization determines whether that identity is permitted to perform the requested action, such as reading a Secret or creating a Pod, on the specific resource involved.
Role-Based Access Control
Role-Based Access Control (RBAC) is the predominant authorization mechanism in Kubernetes, defining Roles or ClusterRoles that describe sets of permitted actions on resources, and binding those roles to specific users, groups, or service accounts through RoleBindings or ClusterRoleBindings.
Principle of Least Privilege
Because RBAC permissions are additive and can be scoped narrowly to specific namespaces, resources, and verbs, cluster operators are encouraged to grant only the minimum permissions a user or workload actually needs, reducing the potential impact of a compromised identity.
Admission Control
A Final Gate Before Persistence
After a request passes authentication and authorization, it passes through admission control, a chain of plugins that can validate or mutate the request before it is persisted, enforcing policies that go beyond simple permission checks.
Validating and Mutating Webhooks
Admission webhooks allow custom logic to be inserted into this chain, such as rejecting Pods that do not meet security baselines, or automatically injecting sidecar containers or default values into incoming requests.
Pod-Level Security Controls
Security Contexts
A Pod or container can specify a security context that constrains its runtime privileges, such as preventing it from running as the root user, restricting the Linux capabilities available to it, or making its root filesystem read-only.
Pod Security Standards
Kubernetes defines a set of Pod Security Standards, ranging from privileged to restricted, describing baseline security postures that can be enforced at the namespace level to prevent Pods from running with unnecessarily broad privileges.
Network-Level Access Control
NetworkPolicies
While RBAC governs access to the Kubernetes API itself, NetworkPolicies govern which Pods are allowed to communicate with which other Pods over the network, forming a complementary layer of access control focused on data plane traffic rather than control plane requests.