Which service account should a Kubernetes pod use?

Give each application its own service account and bind only the roles it needs. The Kubernetes RBAC reference calls this the best practice. Granting permissions to the namespace's default service account hands them to every pod in that namespace that does not name an account.

The default account

Kubernetes creates a default ServiceAccount in every namespace. It has no permissions beyond the default API discovery rights granted to authenticated principals when RBAC is enabled. If you delete it, the control plane recreates it. Pods that do not set serviceAccountName get it.

That is fine until someone binds a role to it. The RBAC reference says permissions given to the default account apply to any pod in the namespace that does not specify a serviceAccountName.

The five options, best to worst

The RBAC reference ranks ways to grant permissions to service accounts:

1. An application-specific service account (best practice).
2. The namespace's default service account.
3. All service accounts in a namespace, using the system:serviceaccounts group for that namespace.
4. A limited role for all service accounts cluster-wide (discouraged).
5. cluster-admin for all service accounts (strongly discouraged). The docs warn it allows any application full access to your cluster.

Doing the best one

Create the account, then bind a role to that subject in the namespace:

kubectl create serviceaccount my-sa -n my-namespace
kubectl create rolebinding my-sa-view --clusterrole=view --serviceaccount=my-namespace:my-sa --namespace=my-namespace

Then set serviceAccountName in the pod template. If the app does not call the Kubernetes API at all, also turn off token mounting, as in our post on disabling token automount.

Common mistakes

• One shared account for a whole namespace, which grows into a union of every app's needs.
• Reusing an operator's powerful account for a helper job.
• Forgetting that creating pods lets someone run as any service account in the namespace, which the good practices page calls out. Control who can create workloads, not only who holds the roles.

A review question

For each service account, answer three things: which pods use it, what roles are bound to it, and whether those pods call the API. If the answer to the last is no, the account should have no bindings.

Safeguard helps on the repository side: policies and gates can check that manifests set an explicit account, and asset discovery helps you keep track of what you run. It does not change cluster RBAC.

A migration path for an existing namespace

If a namespace already relies on the default account, do not remove its bindings in one step. List the pods that use the default account, find which ones actually call the API, create named accounts for those, move the bindings, and only then strip the default. Watch the logs for 403 responses during the change, and keep the old binding file in version control so a rollback is a single commit.

Quick check

Sources

• Service Accounts, Kubernetes docs
• Using RBAC Authorization, Kubernetes docs
• Role Based Access Control Good Practices, Kubernetes docs

Last reviewed: 19 October 2026.