Usually no. Most build and test jobs never call the Kubernetes API, so mounting a service account token gives untrusted build code a credential it does not need. Opt out of automounting for CI pods, and grant a narrowly scoped service account only to jobs that deploy to the cluster.
What happens by default
Kubernetes automatically mounts API credentials for a pod's service account, at the path /var/run/secrets/kubernetes.io/serviceaccount/token. The documentation shows how to opt out: set automountServiceAccountToken: false on the ServiceAccount, or on a particular pod. If both are set, the pod specification takes precedence.
When your CI runs jobs as pods, a build step that runs a downloaded dependency or a pull request's test script can read that file. What it can do next depends on the role bound to the account.
Why this matters more after migration
On a monolithic agent outside the cluster, a job had no cluster credential at all. Moving to in-cluster ephemeral pods can quietly add one. Teams often reuse the runner controller's service account for job pods, which can carry far more permission than a job needs.
A simple decision guide
| Job type | Needs Kubernetes API? | Recommendation |
|---|---|---|
| Compile and unit test | No | Disable token automounting |
| Scan or lint | No | Disable token automounting |
| Build container image | No, unless using in-cluster builders that create pods | Disable, or use a dedicated narrow account |
| Deploy to the cluster | Yes | Dedicated service account with only the verbs and namespaces needed |
| Runner controller | Yes, to create job pods | Separate account from job pods |
Steps
- Create a dedicated service account for CI job pods with automounting off.
- Set the same opt out on the pod template your runner uses, so a missing field cannot re-enable it.
- Keep the runner controller's account separate from the account job pods use.
- For deploy jobs, create a separate account bound to a role limited to one namespace and the exact resources required.
- Prefer short-lived tokens for any job that must reach the API. Kubernetes documents that credentials from a mounted token are revoked after the pod is deleted, within a short window.
- Audit role bindings for CI accounts regularly and remove anything not in use.
Related controls
Dropping the token reduces what a compromised job can do inside the cluster. Pair it with network policy so job pods cannot reach the API server or internal services without a reason, and with resource limits described in CPU and memory limits for CI pods.
Quick check
Will turning off automounting break my builds?
Only builds that call the Kubernetes API from inside the pod. Most do not. Test on one pipeline first and watch for authorization errors.
Is the default service account safe to use?
It depends on the roles bound to it. Create a named account for CI so permissions are visible and reviewable.
Sources
Last reviewed: 19 October 2026.
