You've successfully subscribed to Nuvotex Blog
Great! Next, complete checkout for full access to Nuvotex Blog
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.
Success! Your billing info is updated.
Billing info update failed.

Service accounts in kubernetes 1.24

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.

Daniel Nachtrub
Daniel Nachtrub

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.

# create serviceaccount
kubectl -n temp create sa test-sa
serviceaccount/test-sa created

# create token
# duration is an optional parameter
kubectl -n temp create token test-sa --duration=1440m
eyJhbGciOiJSUzI1N[...]fs4b6Jxw
create token using kubectl

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.

If you're interested, you can decode the token (JSON Web Tokens - jwt.io):

{
  "aud": [
    "https://kubernetes.default.svc.cluster.local"
  ],
  "exp": 1659714374,
  "iat": 1659627974,
  "iss": "https://kubernetes.default.svc.cluster.local",
  "kubernetes.io": {
    "namespace": "temp",
    "serviceaccount": {
      "name": "test-sa",
      "uid": "53399ddd-949d-40d8-a9c5-3406dface09e"
    }
  },
  "nbf": 1659627974,
  "sub": "system:serviceaccount:temp:test-sa"
}
decoded token

Create the secret manually

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.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: test-sa
  namespace: temp
---
apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: test-sa-token
  namespace: temp
  annotations:
    kubernetes.io/service-account.name: "test-ca"
serviceaccount-token secret

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 :-)

https://makeameme.org/meme/you-get-a-048605e09a
ContainerKubernetesCloud

Daniel Nachtrub

Kind of likes computers. Linux foundation certified: LFCS / CKA / CKAD / CKS. Microsoft certified: Cybersecurity Architect Expert & Azure Solutions Architect Expert.