Kubernetes Bearer Token Access

Kubernetes Bearer Token Access is the authentication approach in which a client presents an opaque or structured token in the Authorization: Bearer <token> HTTP header, and the API server validates that token through one of several possible backends — service account token verification, OIDC ID token validation, webhook token review, or a static token file — to resolve it into an authenticated identity. Bearer tokens are the dominant credential type for workload-to-API-server communication and are also common for human access mediated through an identity provider.

How Bearer Token Requests Work

The Authorization Header

A client attaches its token to every request as a standard HTTP header, and the API server's authentication chain inspects this header before evaluating any other request detail.

curl -H "Authorization: Bearer $TOKEN" https://kube-apiserver:6443/api/v1/namespaces

Multiple Possible Validators

Because several authenticators can all consume the same header format, the API server tries each configured bearer-token validator in sequence — first checking whether the token matches the service account issuer's signature, then whether it validates against a configured OIDC issuer, then whether a webhook authenticator accepts it — until one succeeds.

ServiceAccount Bearer Tokens

Structure and Validation

Service account tokens are JWTs signed by the cluster's service-account signing key, containing claims that identify the issuing cluster, the service account's namespace and name, and, for bound tokens, the audience and expiry. The API server validates the signature directly against its own key material rather than calling an external service.

{
  "iss": "https://kubernetes.default.svc",
  "sub": "system:serviceaccount:payments:billing-worker",
  "aud": ["https://kubernetes.default.svc"],
  "exp": 1723145600
}

Bound vs Legacy Tokens

Bound tokens, issued via the TokenRequest API and typically mounted through a projected volume, carry a short expiry and a specific audience; legacy tokens, stored in a Secret of type kubernetes.io/service-account-token, have no expiry and are valid for the API server's default audience indefinitely.

OIDC Bearer Tokens

ID Token Validation

When a user authenticates through an OIDC provider, the resulting ID token is presented as a bearer token on subsequent kubectl requests. The API server validates the token's signature against the provider's published JSON Web Key Set, checks the issuer and audience claims, and extracts username and group claims according to its OIDC configuration.

Credential Plugin Integration

Because OIDC tokens expire quickly, kubectl typically uses a credential plugin (configured in the kubeconfig under users[].user.exec) that transparently refreshes the token using a stored refresh token before it expires, so the user does not need to manually re-authenticate on every command.

users:
- name: oidc-user
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1
      command: kubectl-oidc_login
      args: ["get-token", "--oidc-issuer-url=https://accounts.example.com"]

Webhook-Validated Bearer Tokens

TokenReview Delegation

For tokens that do not match any built-in format, the API server can forward the raw token to an external webhook service as a TokenReview request; the service returns whether the token is authentic and, if so, the identity it represents.

apiVersion: authentication.k8s.io/v1
kind: TokenReview
spec:
  token: "<opaque-token>"

This pattern is used to integrate proprietary or legacy token formats that predate Kubernetes-native identity mechanisms.

Risks Specific to Bearer Tokens

Bearer Semantics Mean Possession Equals Access

Because a bearer token requires no additional proof of possession beyond the token string itself, anyone who obtains a valid token — through a leaked log, an intercepted request, or a compromised container — can use it exactly as the legitimate holder would, until it expires or is otherwise invalidated.

Token Leakage Through Logging

Bearer tokens accidentally written to application logs, error messages, or monitoring traces represent one of the most common real-world exposure paths; log pipelines and observability tooling should be configured to redact Authorization headers by default.

Mitigating Exposure

Short expirations, audience restriction, and avoiding legacy non-expiring service account tokens all reduce the value of a leaked bearer token to an attacker, since a token that expires within the hour has a far smaller exploitation window than one that never expires.