ServiceAccount Tokens and automountServiceAccountToken
The competency says exercise caution in using service accounts, and the caution has three parts: stop mounting credentials into workloads that never call the API, give the ones that do their own identity, and know which token type you are looking at. This guide does all three and measures each.
Cluster Hardening Guide 11 of 40 Intermediate
- Kubernetesapiserver v1.36.4, kubelet v1.36.3
- Runtimecontainerd 2.2.6
- CNICilium 1.18.1
- Built withkubeadm v1.36.3
- TimeAbout 17 min
Projected tokens are the default since 1.24 - audience-bound and expiring. Auto-created kubernetes.io/service-account-token Secrets ended in the same release; any that exist were made by hand.
- Host kernel7.0.0-29
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA6001 | 192.168.0.46 | Ubuntu 26.04 LTS | Control Plane Node (tainted NoSchedule) | 2 Core | 4 GB | 50 GB |
| CKA6001-NODE01 | 192.168.0.47 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA6001-NODE02 | 192.168.0.48 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when a workload is carrying a credential it never needed. This matters because every Pod is handed a mounted token by default, and turning it off where it is not needed is a single patch.
- finding the credential every Pod is handed without ever asking for it
- turning it off with one patch, and confirming the next Pod does not get it
- giving the workload that does need one its own identity and an explicit opt-in
- counting the legacy token Secrets that should not exist any more, and requesting a modern one
Before you start
- guide 9 - the grants these identities carry.
-
The credential every Pod gets without asking
-
Turn it off where it is not needed
-
A dedicated identity for the workload that does need one
-
The token type that should not exist any more