where are tokens created by kubectl create token stored (from v1.24 on)?

user_17095966 0
Viewed 99

This question concerns kubernetes v1.24 and up

So I can create tokens for service accounts with

kubectl create token myserviceaccount

The created token works and serves the purpose, but what I find confusing is that when I kubectl get sa SECRETS field of myserviceaccount is still 0. The token doesn't appear in kubectl get secrets either.

I've also seen that I can pass --bound-object-kind and --bound-object-name to kubectl create token but this doesn't seem to do anything (visible) either...

Is there a way to see created token? And what is the purpose of --bound.. flags?

kubernetes token linux
1 Answers

Regarding your question it seems that the command “kubectl create token myserviceaccount” is not as you expect because according to the official documentation, when you are configuring another SA, the token is automatically created and it is referenced by the service account.

Consider that Any tokens for non-existent service accounts will be cleaned up by the token controller.

Regarding to the configuration of the SA check the link

If you want to know more about how the authentication works in the service account token works you can consult context you can consult the link

Incase that you have Sa set it yo can check how to manage it in the link

For establishing bidirectional trust between a node joining the cluster and a control-plane node, consult the link

If you desire to check the token assigned, you can follow:

Get information about your Kubernetes secret object. Secrets are used to store access credentials:

kubectl get secret --namespace={namespace}

output:

    NAME                   TYPE                                  DATA          AGE                          
    admin.registrykey      kubernetes.io/dockercfg               1             1h                                       
    default-token-2mfqv    kubernetes.io/service-account-token   3             1h

Get details of the service account token.

kubectl get secret default-token-2mfqv --namespace={namespace} -o yaml

Following is a sample output:

apiVersion: v1
data:
 ca.crt: S0tLS1CR...=
 namespace: ZGVmYXVsdA==
 token: ZXlKaGJHY...=
kind: Secret
metadata:
 annotations:
   kubernetes.io/service-account.name: default
   kubernetes.io/service-account.uid: df441c69-f4ba-11e6-8157-525400225b53
 creationTimestamp: 2017-02-17T02:43:33Z
 name: default-token-2mfqv
 namespace: default
 resourceVersion: "37"
 selfLink: /api/v1/namespaces/default/secrets/default-token-2mfqv
 uid: df5f1109-f4ba-11e6-8157-525400225b53
type: kubernetes.io/service-account-token

Note: The token in the sample output is encoded in base64. You must decode the token and then set this token by using kubectl.

Decode and set the base64-encoded token.

kubectl config set-credentials sa-user --token=$(kubectl get secret <secret_name> -o jsonpath={.data.token} | base64 -d)

kubectl config set-context sa-context --user=sa-user

In the command, <secret_name> type the name of your service account secret. Connect to the API server. curl -k -H "Authorization:Bearer {token}"

You can now use kubectl to access your cluster without a time limit for token expiry.

And finally, here you can read about the –bound flag.

****Considering at 1.24 version this have change ****

Once the Pod is running using a SA you could check:

Generate ServiceAccount token manually

Simply generate tokens manually to use in pipelines or whenever we need to contact the K8s Apiserver:

kubectl create token cicd
kubectl create token cicd --duration=999999h

Tip: You can inspect the tokens using for example https://jwt.io, just don’t do this with production tokens!

Create a Secret for the ServiceAccount We can create Secrets manually and assign these to a ServiceAccount:

apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: cicd
  annotations:
    kubernetes.io/service-account.name: "cicd"

if you describe the Secret, we’ll also see that a token was generated for it:

kubectl describe secret cicd

One big difference is though, that the ServiceAccount doesn’t have a Secret section any longer like before:

kubectl get sa cicd -oyaml

To find a Secret belonging to a ServiceAccount we need to search for all Secrets having the proper annotation.

Delete a ServiceAccount If we delete the ServiceAccount then the Secret will also be deleted automatically, just like in previous versions:

kubectl delete sa cicd
kubectl get sa,secret # all gone

You could check the following video for reference

user_198893540
Related