Difficulty: intermediate
Estimated Time: 30-45 minutes

BoxBoat Logo

Now that we know how to deploy our applications, we should limit who can interact with them within the cluster. We may also want to have different types of cluster users: administrators, qa, developers, and so on. In Kubernetes,Role Based Access Control (RBAC) provides this capability.

Let's dig into some of the ways you'll use RBAC, and get used to the ways you'll commonly see it used in the community.

Please email feedback to: [email protected]

KF2 Miscellany - RBAC

Step 1 of 4


RBAC is a fancy term for a common concept: allowing different types of subjects to have different permissions.

First, what are the different subjects available to us? There are regular users, and there are service accounts. Users refers to all of us (human operators) using Kubernetes. Service accounts are for pods (processes) running in the cluster.

One interesting aspect of the design of Kubernetes is that it assumes no user management responsibilities. Kubernetes expects you use to use plugins to authenticate and authorize your users. Additionally, there is no API you can call in Kubernetes to create a new user. Like so many of the other concepts in Kubernetes, this makes it flexible but tougher to get started!

You can, however, interact with service accounts using a lot of the same techniques we have used already.

To list service accounts: kubectl get serviceaccounts

It will generate output similar to the following:

NAMESPACE         NAME                   SECRETS   AGE
default           default                1         1d

Kubernetes has a concept of namespace. Namespaces allow you to separate out resources into different named scopes. Kubernetes itself creates different namespaces, and in the output above we are only looking at the default namespace.

To list the service accounts in all namespaces: kubectl get serviceaccounts --all-namespaces

Which will give something like this:

NAMESPACE         NAME                   SECRETS   AGE
default           default                1         1d
kube-node-lease   default                1         1d
kube-public       default                1         1d
kube-system       default                1         1d
kube-system       heapster               1         1d
kube-system       kubernetes-dashboard   1         1d

We can also describe service account objects:

kubectl describe serviceaccounts default
Name:                default
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   default-token-4qblc
Tokens:              default-token-4qblc
Events:              <none>

Note that the describe output includes a token. This token is stored as a secret in Kubernetes, and it is how the service account authenticates to the Kubernetes API.

A few things happen behind the scenes to make this work when we deploy a pod. Pods use the default service account if one is not provided to them. Once they have a service account, they mount the token for that service account at /var/run/secrets/kubernetes.io/serviceaccount/token within the pod.

Let's open up a shell in a new pod:

kubectl run util --rm -it --image=radial/busyboxplus --restart='Never' -- sh

Now to see the token: cat /var/run/secrets/kubernetes.io/serviceaccount/token



Now, type exit to exit out of the pod. It should be automatically deleted because of how we called kubectl run earlier.

What are the implications of the way that these tokens are mounted?