Jenkins might not be the best starting point in our exploration of ServiceAccounts. Too many things are happening that are out of our control. There's too much "magic" hidden behind Jenkins code. Instead, we'll start with something simpler. We'll run kubectl as a Pod. If we manage to make that work, we should have no problem applying the newly acquired knowledge to Jenkins and other similar use-cases we might have.

Unfortunately, there is no kubectl official image (at least not in Docker Hub), so I built one. The definition is in the vfarcic/kubectl (https://github.com/vfarcic/kubectl) GitHub repository. Let's take a quick look.

1  curl https://raw.githubusercontent.com/vfarcic/kubectl/master/Dockerfile

The Dockerfile is so uneventful and straightforward that there's probably no need going through it. It's a kubectl binary in an alpine based image. Not more, not less.

Let's run it.

 1  kubectl run kubectl 
 2      --image=vfarcic/kubectl 
 3      --restart=Never 
 4      sleep 10000

We should wait for a few moments until the image is pulled and the container that forms the Pod is running.

Let's start by checking out the serviceAccount entry in the Pod specification.

 1  kubectl get pod kubectl 
 2      -o jsonpath="{.spec.serviceAccount}"

The output is as follows.

 1  default

Since we did not specify any ServiceAccount, Kubernetes automatically assigned the default. That account was created with the Namespace.

We might be able to dig a bit more information in the kubectl container.

 1  kubectl exec -it kubectl -- sh

No matter which ServiceAccount is used, Kubernetes always mounts a secret with the information about that account. The secret is mounted inside the /var/run/secrets/kubernetes.io/serviceaccount directory.

 1  cd /var/run/secrets/kubernetes.io/serviceaccount
 2
 3  ls -la

We entered into the secret's directory and listed all the files. The output is as follows.

total 4
... .
... ..
... ..2018_05_07_00_35_25.899750157
... ..data -> ..2018_05_07_00_35_25.899750157
... ca.crt -> ..data/ca.crt
... namespace -> ..data/namespace
... token -> ..data/token

We can see that it created three soft-links (ca.crt, namespace, and token) which are pointing to a directory that contains the actual files. You should be able to guess what those files contain. The token and the certificate are used for authentication when communicating with the API server. The third file contains only the Namespace in which the Pod is running.

Let's try a very simple operation.

 1  kubectl get pods

The output is as follows.

Error from server (Forbidden): pods is forbidden: User 
"system:serviceaccount:default:default" cannot list pods in the 
namespace "default"

We got a similar error message as when we tried to use Jenkins' Kubernetes plugin without credentials. Once again we're faced with limited permissions bound to the default account. We'll change that soon. For now, we'll exit the container and remove the kubectl Pod.

 1  exit
 2
 3  kubectl delete pod kubectl

We saw the limitations of the default account. We'll try to overcome them by creating our own ServiceAccounts.