Kubernetes Security Identity and Access Scope

Kubernetes Security Identity and Access Scope refers to the boundaries of what Kubernetes' native identity and access control mechanisms are designed to address, covering how users, service accounts, and processes are authenticated, how their permitted actions are authorized, and the explicit limits of what these mechanisms handle versus what is delegated to external identity providers and infrastructure.

What Identity Scope Covers

Distinguishing Human and Workload Identities

At its core, this scope covers two distinct categories of identity: human users interacting with the cluster through kubectl or other API clients, and service accounts representing the identity of workloads running within the cluster itself, each authenticated and authorized through related but distinct mechanisms.

Authentication as a Prerequisite Layer

The scope includes how a request's identity is established in the first place, whether through client certificates, bearer tokens, or an external identity provider, before any authorization decision is even considered, since Kubernetes strictly separates the question of who is making a request from the question of what they are permitted to do.

What Authorization Scope Covers

RBAC as the Primary Mechanism

This scope includes Role-Based Access Control, the primary authorization mechanism through which permissions to specific API operations on specific resources are granted to authenticated identities, expressed through Roles, ClusterRoles, and their corresponding bindings.

Namespace and Cluster-Level Granularity

The scope covers both namespace-scoped and cluster-scoped authorization, reflecting the same namespace boundary that governs most other Kubernetes resources, and includes the distinction between permissions that apply only within a specific namespace versus those with cluster-wide reach.

What Falls Outside This Scope

External Identity Provider Management

Kubernetes' identity scope does not include managing the external identity provider itself, corporate single sign-on systems, external OIDC providers, which remain entirely outside Kubernetes and are only integrated with through configured trust relationships, not owned or operated by Kubernetes.

Application-Level Authorization Logic

Fine-grained, application-specific authorization decisions, whether a particular user can view a particular record within an application's own data model, sit entirely outside this scope, which governs access to the Kubernetes API itself, not the internal authorization logic of workloads running on the cluster.

Workload Identity Scope

Service Accounts as In-Cluster Identity

This scope includes how workloads themselves are assigned identity through service accounts, and how that identity is used both for authenticating to the Kubernetes API and, through workload identity federation patterns, for authenticating to external systems entirely outside the cluster.

Admission Control as an Adjacent Boundary

Beyond Simple Allow or Deny

While closely related, admission control, which can mutate or validate requests based on more complex policy beyond simple RBAC allow or deny decisions, represents an adjacent but distinct scope, layered on top of the core authentication and authorization pipeline rather than being part of it directly.