ServiceAccount
Does ZopNight manage 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.
Rules that fire on ServiceAccount
No active rule family targets ServiceAccount today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
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?
kubectl get serviceaccounts -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,SECRETS:.secrets,PULL-SECRETS:.imagePullSecretsThe 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.