Introduction

If you are looking at a Kubernetes ServiceAccount and its secrets list is empty, that is often expected on modern clusters. Kubernetes no longer auto-creates long-lived service account token secrets the way older versions did, so "missing secret" is usually a version or workflow mismatch, not a broken account.

Why the Secret May Not Be Listed

Older Kubernetes clusters commonly created a token secret automatically for each ServiceAccount. Many tutorials were written around that behavior. Newer Kubernetes versions moved toward short-lived, projected service account tokens obtained through the TokenRequest API.

That means this command may show no linked secret:

kubectl get serviceaccount my-sa -o yaml

And that can be perfectly normal.

What Modern Kubernetes Does Instead

Current Kubernetes guidance favors bound, short-lived tokens mounted into Pods automatically when needed. A Pod that uses a ServiceAccount can still authenticate to the API server even if the ServiceAccount object itself does not list a manually created secret.

Example Pod:

1apiVersion: v1
2kind: Pod
3metadata:
4  name: demo
5spec:
6  serviceAccountName: my-sa
7  containers:
8    - name: app
9      image: busybox
10      command: ["sh", "-c", "sleep 3600"]

Inside that Pod, Kubernetes projects a token into the filesystem unless automounting is disabled.

If You Need a Token Right Now

On modern clusters, the best way to get a token for a ServiceAccount is usually:

kubectl create token my-sa

That asks the API server to mint a token instead of hunting for an auto-generated secret that may never exist.

This is the most direct fix when the real goal is "I need credentials for this ServiceAccount," not "I specifically need a Secret object."

If You Truly Need a Secret Object

Some older integrations still expect a Kubernetes Secret containing a service account token. In that case, create one explicitly:

1apiVersion: v1
2kind: Secret
3metadata:
4  name: my-sa-token
5  annotations:
6    kubernetes.io/service-account.name: my-sa
7type: kubernetes.io/service-account-token

Apply it:

kubectl apply -f sa-token-secret.yaml

Then inspect it:

kubectl get secret my-sa-token -o yaml

Kubernetes can populate the token data for that Secret because of the annotation tying it to the ServiceAccount.

Check Whether Automounting Is Disabled

Sometimes the confusion is not about Secret creation at all. A Pod may be using the ServiceAccount, but the token is not mounted because automounting is turned off.

Check both the ServiceAccount and Pod specs for:

automountServiceAccountToken: false

If that setting is present, the Pod will not receive the default projected token even though the ServiceAccount exists normally.

Verify RBAC and Namespace Assumptions

Another common mistake is looking in the wrong namespace or assuming a secret belongs to a different ServiceAccount.

Useful checks:

kubectl get serviceaccount my-sa -n my-namespace -o yaml
kubectl get secrets -n my-namespace
kubectl describe serviceaccount my-sa -n my-namespace

If the ServiceAccount exists in one namespace and you inspect another, it can look like secrets disappeared when the real problem is scope.

Choose the Fix Based on the Real Need

Use this decision rule:

• need a Pod to authenticate: use the ServiceAccount normally and rely on projected tokens
• need a one-off token value: use kubectl create token
• need a Secret object for a legacy integration: create a kubernetes.io/service-account-token Secret explicitly

That is more reliable than forcing old tutorials onto modern Kubernetes behavior.

Common Pitfalls

• Expecting every ServiceAccount to show an auto-created token secret on modern Kubernetes.
• Searching for a Secret when the Pod is already using a projected token correctly.
• Forgetting that kubectl create token is the preferred way to obtain a token on newer clusters.
• Looking in the wrong namespace and assuming the ServiceAccount or Secret is missing.
• Setting automountServiceAccountToken: false and then wondering why no token appears in the Pod.

Summary

• An empty ServiceAccount secrets list is often normal on newer Kubernetes versions.
• Modern clusters prefer short-lived projected tokens instead of auto-generated long-lived Secret objects.
• Use kubectl create token when you need a token value directly.
• Create a kubernetes.io/service-account-token Secret only if a legacy workflow truly requires it.
• Check namespace and automount settings before assuming anything is broken.