Kubernetes ServiceAccount Management

Kubernetes ServiceAccount Management is the operational practice of creating, scoping, and maintaining the identities that workloads use to authenticate to the Kubernetes API server. A ServiceAccount is a namespaced API object with its own lifecycle, distinct from the human user identities the cluster delegates to external providers, and managing it well means treating every workload's API access as a deliberate, minimal, and reviewable grant rather than an incidental default.

The ServiceAccount Object

Creation and Namespace Scope

A ServiceAccount is created like any namespaced resource and exists only within the namespace it was created in. Every namespace automatically receives a default service account at creation time, which pods use implicitly if no serviceAccountName is specified in their pod spec.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: billing-worker
  namespace: payments

Assigning a ServiceAccount to a Workload

A pod references its identity through spec.serviceAccountName. Controllers such as Deployment, StatefulSet, and Job propagate this field to every pod they create, so the service account is set once at the workload level rather than per pod.

apiVersion: v1
kind: Pod
metadata:
  name: billing-worker-pod
spec:
  serviceAccountName: billing-worker
  containers:
  - name: worker
    image: registry.internal/billing-worker:1.4.2

Token Issuance

Bound Service Account Tokens

Since Kubernetes 1.22, tokens are issued through the TokenRequest API and mounted using a projected volume, producing a JWT that is bound to a specific audience, has a configurable expiry (defaulting to one hour, refreshed automatically by the kubelet), and is tied to the specific pod that requested it.

volumes:
- name: sa-token
  projected:
    sources:
    - serviceAccountToken:
        expirationSeconds: 3600
        audience: vault
        path: token

Disabling Automatic Token Mounts

Workloads that never call the Kubernetes API should disable automounting to eliminate an unnecessary credential inside the container filesystem, using automountServiceAccountToken: false on either the ServiceAccount or the individual pod spec.

Scoping Permissions

One ServiceAccount per Workload Role

The recommended pattern assigns a distinct service account to each logically separate workload, then binds a Role granting only the verbs and resources that workload requires, rather than reusing a single shared service account across multiple applications with different needs.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: billing-worker-binding
  namespace: payments
subjects:
- kind: ServiceAccount
  name: billing-worker
  namespace: payments
roleRef:
  kind: Role
  name: read-configmaps
  apiGroup: rbac.authorization.k8s.io

Avoiding the default ServiceAccount

Because the default service account is implicitly attached to any pod that does not specify otherwise, leaving it bound to broad permissions — or even leaving its token auto-mounted — creates an unintended attack surface for every workload in the namespace that omitted an explicit serviceAccountName.

Cross-Cluster and Cross-Cloud Identity

Service Account Federation

Cloud providers extend the service account model so that a Kubernetes service account can assume a cloud IAM identity without storing cloud credentials in the cluster: IRSA on AWS, Workload Identity on GKE, and Azure AD Workload Identity all associate a Kubernetes service account with a cloud-side role through an annotation or federation configuration, letting the projected token double as proof of cloud identity.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: billing-worker
  namespace: payments
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/billing-worker-role

Lifecycle and Hygiene

Rotation

Because bound tokens expire automatically and are refreshed transparently by the kubelet, rotation for modern clusters is largely automatic; legacy long-lived secret-based tokens, by contrast, require manual rotation and deletion of the associated Secret object to invalidate.

Cleanup

Deleting a ServiceAccount immediately invalidates any tokens bound to it, including tokens already mounted into running pods, since the API server checks the service account's existence and UID on every authenticated request using that token.

Auditing

kubectl get serviceaccounts --all-namespaces combined with a review of each account's bound roles gives a complete inventory of workload identities and their granted permissions, which should be reconciled periodically against the set of workloads actually deployed to catch orphaned or over-permissioned accounts.