Introduction

If a newly created Kubernetes ServiceAccount does not get a long-lived token Secret, that is usually expected behavior on modern clusters. Recent Kubernetes versions stopped automatically creating legacy secret-based service account tokens and instead prefer short-lived projected tokens mounted directly into Pods.

What Changed

Older Kubernetes clusters often created a Secret object automatically for each service account. That secret contained a token and was sometimes referenced directly by applications.

Modern Kubernetes moved away from that pattern for security reasons. The recommended model is now:

• use the TokenRequest API to mint short-lived tokens
• mount projected service account tokens into Pods when needed
• avoid creating long-lived token secrets unless there is a specific compatibility reason

So if you create a ServiceAccount and do not see a token secret appear, that usually means the cluster is using the newer behavior rather than failing.

What Pod Mounting Looks Like Now

A Pod can still receive a service account token automatically if automountServiceAccountToken is enabled. The difference is that the token is typically projected into the filesystem instead of coming from an auto-created secret object.

A minimal example looks like this:

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

Inside the running Pod, the token is usually available under the standard projected path:

/var/run/secrets/kubernetes.io/serviceaccount/token

That file can exist even when there is no separate Secret resource created for the service account.

When Automatic Mounting Is Disabled

If the Pod does not receive a token at all, check whether automatic mounting has been disabled.

You can disable it at the service-account level:

1apiVersion: v1
2kind: ServiceAccount
3metadata:
4  name: app-sa
5automountServiceAccountToken: false

Or at the Pod level:

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

If either of those settings disables automounting, the token will not appear in the container unless you add an explicit projected volume.

How to Request a Token Explicitly

If you need a token outside the default mounting flow, use kubectl create token on supported clusters.

kubectl create token app-sa

That asks the API server to issue a token for the service account using the newer token mechanism.

This is usually better than trying to recreate the old secret-based workflow unless you are supporting a legacy integration that specifically expects a Secret object.

If You Truly Need a Secret-Based Token

There are compatibility cases where an external system expects a Kubernetes Secret containing a service account token. That can still be created deliberately, but it is no longer something to rely on as an automatic default.

In other words, treat secret-based service account tokens as an explicit compatibility choice, not as the normal path for new workloads.

Common Pitfalls

Assuming that "no token secret exists" means the service account is broken is the most common misunderstanding. On current clusters, that is often normal.

Looking only for a Secret object and not checking the mounted token file inside the Pod is another mistake.

Forgetting that automountServiceAccountToken: false can be set on either the service account or the Pod also causes confusion.

Finally, do not build new systems around long-lived secret-based tokens unless you have a real reason to do so. The projected-token model is the safer default.

Summary

• modern Kubernetes usually does not auto-create legacy token Secret objects for every service account
• Pods can still receive a mounted service account token through projected volumes
• check automountServiceAccountToken if no token appears inside the Pod
• use kubectl create token when you need an explicit token from the current API flow
• treat secret-based service account tokens as a compatibility path, not the modern default