Create a Token-based Kubeconfig

Preface

With this method we will create a ServiceAccount and a token that can then be retrieved and assign role and permission.

ServiceAccount (SA)

Creation of the ServiceAccount is done as follow:

$ kubectl -n default create serviceaccount laurent-sa

serviceaccount/laurent-sa created

Assign Role

We then assign a role in this example we will assign Cluster Admin role:

$ kubectl create clusterrolebinding kubeconfig-cluster-admin-token --clusterrole=cluster-admin --serviceaccount=default:laurent-sa

clusterrolebinding.rbac.authorization.k8s.io/kubeconfig-cluster-admin-token created

Secret and Token

We will then need to create a secret and retrieve the token from this secret.

We create a manifest token-secret-admin.yml:

token-secret-admin.yml

---
apiVersion: v1
kind: Secret
metadata:
  name: kubeconfig-cluster-admin-token
  namespace: default
  annotations:
    kubernetes.io/service-account.name: laurent-sa
type: kubernetes.io/service-account-token

We deploy the manifest:

$ kubectl apply -f token-secret-admin.yml

secret/kubeconfig-cluster-admin-token created

We then retrieve the token:

$ kubectl describe secrets kubeconfig-cluster-admin-token

Name:         kubeconfig-cluster-admin-token
Namespace:    default
Labels:       
Annotations:  kubernetes.io/service-account.name: laurent-sa
              kubernetes.io/service-account.uid: 084d0a7a-bb23-4b0b-81b8-97ba250d1755

Type:  kubernetes.io/service-account-token

Data
====
ca.crt:     1070 bytes
namespace:  7 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6InBqZUFJOFJvbnNWQ19odGJrdGwzTnY3TXRJX29HS0dIekVsQmlJZzZ6R0kifQ.eyJ [...]

You can also just retrieve the decoded token like this:

$ kubectl -n default get secret kubeconfig-cluster-admin-token  -o jsonpath='{.data.token}' | base64 --decode

eyJhbGciOiJSUzI1NiIsImtpZCI6InBqZUFJOFJvbnNWQ19odGJrdGwzTnY3TXRJX29HS0dIekVsQmlJZzZ6R0kifQ.eyJ [...]

kubeconfig

We can now build the kubeconfig with the ServiceAccount and its token.

Like mention earlier in this document we copy from the kubeconfig downloaded from the customer portal as the base for our new kubeconfig

cp <path_to_saved_kubeconfig> ~/certs/laurent.kubeconfig

Then modified the users part it like this without touching the cluster part:

laurent-token.kubeconfig

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FUR [...]
    server: https://212.7.193.11:6443
  name: k8s-0000001
contexts:
- context:
    cluster: k8s-0000001
    user: laurent-sa # <- This is what need to be change
  name: k8s-0000001
current-context: k8s-0000001
kind: Config
preferences: {}
users:
- name: laurent-sa # <- This is what need to be change
  user: # Change the certificate section for a token section as shown below.
    token: eyJhbGciOiJSUzI1NiIsImtpZCI6InBqZUFJOFJvbnNWQ19odGJrdGwzTnY3TXRJX29HS0dIekVsQmlJZzZ6R0kifQ.eyJ [...] # <- This is what need to be change

Validation

Because we already assigned the cluster admin role to this ServiceAccount we should be able to get the cluster info:

$ kubectl --kubeconfig laurent-token.kubeconfig cluster-info

Kubernetes control plane is running at https://:6443
CoreDNS is running at https://:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

Conclusion

We can see that there is multiple way to authenticate against the API server, we demonstrate with certificates and bearer token but you can also see more ways on the official Kubernetes documentation in the authentication section.