Service Accounts

A ServiceAccount is the identity a Pod uses — to call the Kubernetes API, and, through federation, to call cloud services. Where humans authenticate via OIDC, workloads authenticate as ServiceAccounts. It is the workload half of the identity story.

The modern ServiceAccount model is built on short-lived, automatically rotated tokens and federation to cloud IAM, which together end the era of long-lived embedded credentials. Knowing how it works is key to running least-privilege workloads.

Workload Identity, Not Human Identity

A ServiceAccount is a namespaced object that represents a workload. Every Pod runs as one — if you don't specify it, the namespace's default ServiceAccount, which is exactly why the default is dangerous when over-permissioned. RBAC bindings target ServiceAccounts just like users, so a Pod's permissions are whatever its ServiceAccount has been granted.

apiVersion: v1
kind: Pod
metadata:
  name: api
spec:
  serviceAccountName: api-sa
  automountServiceAccountToken: true
  containers:
    - name: api
      image: my-api:1.0

Bound and Projected Tokens

Originally a ServiceAccount had a long-lived token stored in a Secret — a standing credential that never expired. The modern approach is the projected, bound token: the kubelet requests a short-lived token, scoped (audience-bound) and time-limited, and mounts it into the Pod, rotating it automatically. There is no permanent secret to leak. If a Pod does not need API access at all, set automountServiceAccountToken: false so no token is mounted.

Federation to Cloud IAM

The same ServiceAccount identity can be exchanged for cloud credentials through workload-identity federation — AWS IRSA / EKS Pod Identity, GKE Workload Identity, Azure Workload Identity. The Pod presents its projected token, the cloud trusts the cluster's OIDC issuer, and the Pod receives temporary cloud credentials. No access keys are stored in the Pod, in an image, or in a Secret. This is the right way for a Pod to reach a cloud database or bucket.

Least Privilege for Workloads

The practical guidance is: give each workload its own ServiceAccount with a minimal RBAC role, rather than letting everything share the over-broad default. Disable token automounting where API access isn't needed. And prefer federation over any stored cloud credential. A compromised Pod is then limited to exactly what its ServiceAccount allows — which, done right, is very little.