Kubernetes 1.24 changed the way serviceaccounttokens are presented by default on the cluster itself. If you need to retrieve the token, you mostly use a secret for this. This guide shows how to do this in kubernetes >= 1.24.
Kubernetes is under active development and breaking changes are mostly expected during version upgrades. In 1.24 one change that might be important for you is that serviceaccounts don't generate tokens as secrets by default anymore. This only affects the environment, within the pods everything stays as before.
Create a token using kubectl
In case you want to create a token manually, this can be done using kubectl create token. Super fast & easy.
You can use this token wherever you need.
Duration The default duration is 3600s (as of today). So, if you need tokens that wont' expire that soon, use the duration parameter or provide a custom token.
In most cases you won't create service accounts by hand but rather using some deployment like helm. To achieve this with a custom secret, you can create a secret of type kubernetes.io/service-account-token.
The annotation will link the token to the serviceaccount.
Deletion Deleting the serviceaccount will cause a propagation of the operation to the token, so you don't need to care about this in case of cleanup.
conditional deployment If you're using helm to deploy resources, it's a good practice to verify the kubernetes version and deploy in this case the token only if version >= 1.24.0. semverCompare is your friend in this case.
That's it - quite easy, you just need to know it :-)
On a recent project I've been stumbling on the case that kerberos tickets have been inadvertently shared across containers on a node - which obviously caught my attention as I'm not keen on sharing such secrets across workloads. This post describes why this happens and what to do to prevent this.