# ServiceAccount

> ServiceAccounts are the identity pods authenticate with; any pod naming none runs as its namespace's default account. ZopNight records 2 counts per account, secretCount and imagePullSecretCount, plus labels, feeding RBAC analysis of workload identity. Nonzero secret counts usually mark legacy long-lived tokens, since modern clusters issue short-lived projected tokens instead.

Source: https://zop.dev/integrations/kubernetes/serviceaccount
Updated: 2026-08-19

---

A ServiceAccount is the identity a pod presents to the Kubernetes API and, through cloud identity bindings, often to cloud APIs beyond the cluster. Every pod runs as one whether anyone chose it or not, which is what makes the type worth inventorying even though it costs nothing.

## Every pod runs as somebody

A pod that names no service account gets its namespace's `default` account automatically. That default behavior is the root of most service-account sprawl reviews: workloads that need no API access at all still carry an identity, and workloads that need specific access are often lazily granted through the shared default account instead of one of their own. That makes the default account's permissions the effective permissions of everything in the namespace.

## Two counts and a name

Discovery keeps each account's namespace, its `secretCount`, and its `imagePullSecretCount`, plus labels. The counts are small but diagnostic. Mountable secrets on an account are the legacy long-lived-token pattern; modern clusters issue short-lived projected tokens instead, so a nonzero secret count on a hand-made account frequently marks credentials from an earlier era that nobody rotated. Image pull secrets on an account, by contrast, are the standard way to give a namespace registry access without editing every pod spec, so that count reads as intentional wiring.

## From cluster identity to cloud identity

The service account is also where cluster RBAC meets cloud IAM: workload-identity mechanisms on the managed clouds bind a Kubernetes service account to a cloud-side role, letting pods call cloud APIs without stored keys. That makes over-privileged accounts a lateral-movement concern in both directions: inside the cluster through RoleBindings, outside it through whatever the bound cloud role permits. RBAC review therefore starts from accounts: what do the bindings that reference this identity actually grant?

```bash
kubectl get serviceaccounts -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,SECRETS:.secrets,PULL-SECRETS:.imagePullSecrets
```

## The audit shape

Three lists cover it: accounts referenced by no binding and no pod (deletable clutter), pods running as `default` in namespaces where bindings grant that account real permissions (the risk), and accounts with legacy secret tokens (the rotation backlog). All 3 are derivable from this inventory joined to the RBAC objects.