We've created a service account in the previous section; now, let's see how to use a service account token to do the authentication. We'll have to retrieve the token first:

// check the details of the secret
# kubectl get secret chapter8-serviceaccount-token-nxh47 -o yaml
apiVersion: v1
data:
  ca.crt: <base64 encoded>
  namespace: ZGVmYXVsdA==
  token: <bearer token, base64 encoded>
kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: chapter8-serviceaccount
    name: chapter8-serviceaccount-token-nxh47
  namespace: default
  ...
type: kubernetes.io/service-account-token

We can see that the three items under the data are all base64-encoded. We can decode them easily with the echo "encoded content" | base64 --decode command in Linux. For example, we can decode encoded namespace content:

# echo "ZGVmYXVsdA==" | base64 --decode 
default 

Using the same command we can get the bearer token and use it in a request. The API server expects a HTTP header of Authorization: Bearer $TOKEN along with the request. The following is an example of how to use the token to authenticate and make a request directly to the API server.

Firstly, we'll have to get our decoded token:

// get the decoded token from secret chapter8-serviceaccount-token-nxh47 
# TOKEN=`echo "<bearer token, base64 encoded>" | base64 --decode` 

Secondly, we'll have to decode ca.crt as well:

// get the decoded ca.crt from secret chapter8-serviceaccount-token-nxh47 
# echo "<ca.crt, base64 encoded>" | base64 --decode > cert 

Next, we'll need to know what the API server is. Using the kubectl config view command, we can get a list of servers:

# kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: https://api.demo-k8s.net
  name: demo-k8s.net
- cluster:
    certificate-authority: /Users/chloelee/.minikube/ca.crt
    server: https://192.168.99.100:8443
  name: minikube
...

Find the one you're currently using. In this example, we're using minikube. The server is at https://192.168.99.100:8443.

Then we should be good to go! We'll request the API endpoint directly via https://$APISERVER/api with--cacert and --header

# curl --cacert cert https://192.168.99.100:8443/api --header "Authorization: Bearer $TOKEN"
{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.0.2.15:8443"
    }
  ]
}

We can see that the available version is v1. Let's see what we have in /api/v1 endpoint:

# curl --cacert cert https://192.168.99.100:8443/api/v1 --header "Authorization: Bearer $TOKEN"
{
  "kind": "APIResourceList",
  "groupVersion": "v1",
  "resources": [
   ...
   {
      "name": "configmaps",
      "singularName": "",
      "namespaced": true,
      "kind": "ConfigMap",
      "verbs": [
        "create",
        "delete",
        "deletecollection",
        "get",
        "list",
        "patch",
        "update",
        "watch"
      ],      
      "shortNames": ["cm"]
    }
  ],  ...
}

It will list all the endpoints and verbs we requested. Let's take configmaps as an example and grep the name:

# curl --cacert cert https://192.168.99.100:8443/api/v1/configmaps --header "Authorization: Bearer $TOKEN" |grep "name"
        "name": "extension-apiserver-authentication",
        "name": "ingress-controller-leader-nginx",
        "name": "kube-dns",
        "name": "nginx-load-balancer-conf",

There are four default configmaps listed in my cluster in this example. We can use kubectl to verify this. The result should match the ones we previously got:

# kubectl get configmaps --all-namespaces
NAMESPACE     NAME                                 DATA      AGE
kube-system   extension-apiserver-authentication   6         6d
kube-system   ingress-controller-leader-nginx      0         6d
kube-system   kube-dns                             0         6d
kube-system   nginx-load-balancer-conf             1         6d