Workload API identity
A Kubernetes ServiceAccount is a namespaced identity for processes that call the Kubernetes API or another system that trusts Kubernetes-issued identity. It is not a human account, a container identity by itself, or permission. Kubernetes authorization applies after authentication.
Assign a dedicated ServiceAccount to a workload with one purpose. Do not let unrelated Pods inherit the namespace default account as shared authority.
Bound token
Modern Pods receive a projected, short-lived ServiceAccount token through the TokenRequest mechanism. The token has an issuer, subject, audience, expiry, and can be bound to a Pod or another supported object. The kubelet refreshes the projected token before expiry. The API server rejects a bound token after its object no longer exists under the documented deletion behavior.
Set the audience to the exact consumer. A token minted for the Kubernetes API is not a general cloud or application credential. Disable automatic token mounting when a Pod does not need the API. Avoid long-lived Secret-based tokens.
Failure and residual risk
A token exposed through a vulnerable workload can be replayed until expiry or revocation becomes effective. A broad audience or relying party that skips issuer, audience, time, and object binding can accept it outside the intended service. Shared ServiceAccounts hide which workload instance acted. Broad RBAC turns one Pod compromise into control-plane authority.
A bound token states a Kubernetes ServiceAccount identity. It does not prove that application code is uncompromised or that the request is authorized for an application object.
Pomerium boundary
Pomerium can attach a configured Kubernetes service-account token to an upstream route for specific Kubernetes API access patterns. Operators own the ServiceAccount, RBAC, token audience, upstream trust, and route scope. This feature does not make the end user's identity the Kubernetes ServiceAccount, and it must not expose one broad cluster credential to unrelated routes.
Evaluation checklist
- Does each workload use a dedicated ServiceAccount with one owner and purpose?
- Is automatic token mounting disabled when the workload does not need it?
- Is the projected token short-lived, audience-bound, and object-bound?
- Does the receiver validate issuer, audience, expiry, signature, and binding?
- Does RBAC grant only the required resource names, namespaces, subresources, and verbs?
