Wiki · Concept · Last reviewed June 25, 2026

Kubernetes ServiceAccount Tokens

Kubernetes ServiceAccount tokens are workload credentials that let Pods authenticate as a ServiceAccount, making them a practical access-control record for AI infrastructure.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: Kubernetes, ServiceAccounts, tokens, workload identity, AI infrastructure

Definition

Kubernetes ServiceAccount tokens are bearer credentials that represent a Kubernetes ServiceAccount. The official Service Accounts page defines a service account as a non-human account that gives a distinct identity inside a Kubernetes cluster. Application Pods, system components, and external entities can use that identity to authenticate to the API server or to support identity-based policies.

For Spiralism, the token is not just an implementation detail. In a cluster running model endpoints, agent workers, browser controllers, retrievers, or evaluation harnesses, it is the credential by which machine labor says, "this is the workload speaking." That claim needs ownership, scope, expiration, and audit evidence.

How It Works

ServiceAccounts are namespaced Kubernetes API objects. Every namespace gets a default ServiceAccount, and a Pod without spec.serviceAccountName gets that default account. A Pod can instead name a dedicated ServiceAccount when the Pod, or its workload template, is created. Authentication is separate from authorization: once the token identifies the ServiceAccount, RBAC or another authorization mechanism decides which API actions are allowed.

By default, Kubernetes provides credentials for the assigned ServiceAccount to the Pod. Operators can opt out with automountServiceAccountToken: false on the ServiceAccount or Pod; the Pod setting takes precedence. Many AI containers do not need Kubernetes API access. A tokenizer, batch inference worker, or document parser should not receive an ambient API credential unless it uses one.

Modern Kubernetes uses the TokenRequest API and projected volumes for most in-Pod ServiceAccount credentials. The Service Accounts documentation says that in v1.22 and later Kubernetes gets a short-lived, automatically rotating token using TokenRequest and mounts it as a projected volume. Explicit token projection can request properties such as audience, validity duration, and file path. The kubelet requests, stores, refreshes, and mounts the token for the Pod.

Bound tokens reduce the blast radius of a copied credential. The service account administration guide says a token served for TokenRequest expires when the bound Pod is deleted or after a defined lifespan, with a one-hour default in the described mechanism, and that the token is bound to the specific Pod with the Kubernetes API server as audience. Kubernetes can still create long-lived kubernetes.io/service-account-token Secrets, but the documentation recommends TokenRequest for short-lived API access tokens instead.

Agent Context

Agentic systems often run as collections of Pods: a front end, tool runner, sandbox spawner, vector indexer, evaluator, and queue worker. If those Pods share a broad ServiceAccount, a container compromise can become whatever Kubernetes authority that account has. The incident may begin in application space, but the damage boundary is defined by cluster identity.

ServiceAccount tokens belong in the same review folder as model access keys, tool allowlists, and deployment manifests. They answer questions easy to miss in AI reviews: which workload can list Pods, read Secrets, create Jobs, patch Deployments, or watch events? Which tokens are mounted by default because no one opted out?

Governance Use

A governance-grade record should preserve namespace, ServiceAccount name, workload owner, serviceAccountName, automount settings, projected volume configuration, token audience, requested expiration, mount path, RBAC bindings, related Secrets, TokenReview use, audit events, and the business purpose for Kubernetes API access. For AI platforms, the record should also identify public inference, internal evaluation, tool execution, retrieval, batch support, or administrative automation.

The practical control is to make token access explicit. Sensitive workloads should use dedicated ServiceAccounts rather than the namespace default. Pods that do not call the API server should opt out of automatic token mounting. Cluster-wide permissions should have a named reason. Long-lived Secret-based tokens should be visible exceptions, not background residue.

Limits

A ServiceAccount token authenticates a workload; it does not by itself authorize every action, isolate a container, prevent data exfiltration, validate model behavior, or prove that an agent is acting within policy. RBAC, admission control, network policy, secret management, runtime isolation, logging, and incident response still carry separate work.

Offline JWT validation has another limit. The administration guide notes that services validating Kubernetes ServiceAccount JWTs offline do not verify that embedded bound-object claims are still current; clients needing that assurance must use TokenReview against the API server. Cloud workload identity systems and service meshes may build on or exchange Kubernetes identity, but those claims require provider-specific documentation.

Source Discipline

Claims about ServiceAccount identity, default assignment, automounting, projected tokens, TokenRequest, legacy token Secrets, and TokenReview should cite Kubernetes documentation. Claims about EKS, GKE, AKS, SPIFFE, Istio, Linkerd, Vault, or an AI gateway implementation should cite those systems separately.

The evidence to keep is operational: manifests, RBAC bindings, admission decisions, audit logs, token review configuration, Secret inventory, cluster version, and controller behavior.

Spiralist Reading

Spiralism reads the ServiceAccount token as a compact delegation record.

The file in the container is small, but the permission behind it can be large. It says that a process may speak with the voice of a workload, a namespace, and sometimes an institution. Good practice is to keep that voice narrow, named, temporary, and reviewable.

Sources

Return to Wiki