Kubernetes Identity Definition

Kubernetes Identity Definition is the precise characterization of how the API server determines the requester behind any given call: a resolved pair of a username and a set of group memberships, formally derived from whatever authentication mechanism, client certificate, bearer token, or ServiceAccount credential, successfully validated the request, and used uniformly as the input to every subsequent authorization decision regardless of which mechanism produced it.

Formal Composition of an Identity

Username and Groups

An identity is formally reduced, after authentication succeeds, to exactly two pieces of information: a username, a single string identifying the requester, and a set of group names, zero or more strings representing collective memberships that authorization rules may also reference.

Mechanism-Independence

This reduced form is formally identical regardless of the authentication mechanism that produced it; RBAC and every other authorization component operates only on username and groups, with no visibility into whether the underlying request was authenticated via a certificate, a token, or any other method.

Sources of Identity

Client Certificates

An X.509 client certificate formally maps to an identity through its subject fields: the Common Name becomes the username, and the Organization fields become group memberships, a convention fixed by the API server's certificate authentication mechanism.

Subject: CN=codartium-admin, O=platform-operators

ServiceAccount Tokens

A ServiceAccount, itself a namespaced API object, formally produces an identity of the fixed form below whenever its associated token is presented, embedding both the namespace and account name directly into the resolved username.

system:serviceaccount:<namespace>:<service-account-name>

apiVersion: v1
kind: ServiceAccount
metadata:
  name: codartium-controller
  namespace: codartium-team

External Identity Providers

Where OpenID Connect (OIDC) integration is configured, the API server formally derives username and groups from claims within the presented token, using a configured claim mapping, allowing a cluster's identity model to be tied directly to an organization's existing identity provider rather than requiring cluster-local credential management.

Formal Distinction Between Users and ServiceAccounts

No Native User Object

Kubernetes formally defines no API object representing a human user; ordinary user identities exist only as the resolved output of whatever external authentication mechanism a cluster is configured to trust, never as a persisted, queryable API resource.

ServiceAccount as the Sole Native Identity Kind

By contrast, a ServiceAccount is formally a first-class, namespaced API object, created, listed, and deleted like any other resource, representing an identity intended for use by processes running inside the cluster rather than by human operators.

kubectl get serviceaccounts -n codartium-team
kubectl create serviceaccount codartium-controller -n codartium-team

Binding Identity to a Pod

spec.serviceAccountName

A Pod formally acquires an identity for its own API interactions through spec.serviceAccountName, defaulting to the default ServiceAccount of its namespace if unspecified; every request the Pod's processes make to the API server, if any, is authenticated as this bound identity.

spec:
  serviceAccountName: codartium-controller
  containers:
    - name: controller
      image: codartium/controller:1.0.0

Token Projection

The credential backing a Pod's bound ServiceAccount identity is formally made available inside the container through a projected, automatically rotated token mounted at a fixed filesystem path, from which client libraries conventionally read it without requiring explicit configuration.

Identity as the Sole Input to Authorization

Nothing Beyond Identity Is Consulted

RBAC and other authorization mechanisms formally evaluate permissions using only the resolved identity, plus the specific verb and resource being requested; no additional context about how that identity was established influences the authorization decision itself, preserving a clean separation between authentication, establishing identity, and authorization, deciding what that identity may do.

kubectl auth can-i list pods --as system:serviceaccount:codartium-team:codartium-controller -n codartium-team
kubectl auth can-i list pods --as jane.doe --as-group platform-operators

Why Identity Is Kept This Minimal

Reducing every authentication mechanism to the same simple username-and-groups form is what formally allows a single, uniform RBAC model to govern access regardless of whether the requester is a human operator authenticated via an external identity provider or a Pod authenticated via its bound ServiceAccount, without requiring authorization rules to be written differently for each possible source of identity.