On defaults in Kubernetes RBAC

In Kubernetes, the Role-Based Access Control (RBAC) method defines a number of default roles and bindings. In this article, we will have a closer look at some of those and discuss where and how to use them.

Let's start with the user-facing cluster roles:

$ kubectl get clusterroles | grep -v '^system'
NAME                                                                   AGE
admin                                                                  33h
cluster-admin                                                          33h
edit                                                                   33h
view                                                                   33h

So we found four cluster roles, admin, cluster-admin, edit, and view available by default in this setup (a Kubernetes 1.11 install). What can you do with them? Using commands such as kubectl get clusterrole/admin -o yaml reveals what each of these roles is about:

Both cluster-admin and admin give read-write access to all (respectively many) resources. In general, if you want to make someone superuser or cluster root, then use the cluster-admin cluster-role with a cluster role binding. Think hard if you want to do that. If your organization sports the responsibility of a namespace admin, you can use either cluster-admin and admin with a role binding and that enables this person then to do everything or mostly everything with all (respectively almost all) resources in the namespace the role binding exists. The only real difference between cluster-admin and admin is that the latter is a little more restrictive when it comes to certain resources such as the namespaces themselves.
The edit role allows one to create, update, delete many of the normal core resources such as deployments, services, or configmaps, however manipulating RBAC permissions is not allowed.
The view role is for read-only access on most resources (besides secrets).

Oftentimes these default roles are a nice starting point for human users. For apps, in reality you will likely end up using tools like audit2rbac to figure out tailored permissions, based on concrete access patterns.

Next, we have a look at the one and only default cluster binding cluster-admin which in my install is defined as follows (edited in the following for clarity by dropping irrelevant fields):

$ kubectl get clusterrolebindings/cluster-admin -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:masters

Seems that the cluster role binding cluster-admin gives the system:masters group super powers; that's good to know but not directly super useful.

OK, let's move on with service accounts (the identities for non-human users such as Kubernetes components like nodes, controllers, or your own app):

$ kubectl get sa --all-namespaces
NAMESPACE     NAME                                 SECRETS   AGE
default       default                              1         1d
kube-public   default                              1         1d
kube-system   attachdetach-controller              1         1d
kube-system   bootstrap-signer                     1         1d
kube-system   certificate-controller               1         1d
kube-system   clusterrole-aggregation-controller   1         1d
kube-system   coredns                              1         1d
kube-system   cronjob-controller                   1         1d
kube-system   daemon-set-controller                1         1d
kube-system   default                              1         1d
kube-system   deployment-controller                1         1d
kube-system   disruption-controller                1         1d
kube-system   endpoint-controller                  1         1d
kube-system   expand-controller                    1         1d
kube-system   generic-garbage-collector            1         1d
kube-system   horizontal-pod-autoscaler            1         1d
kube-system   job-controller                       1         1d
kube-system   kube-proxy                           1         1d
kube-system   namespace-controller                 1         1d
kube-system   nginx-ingress                        1         1d
kube-system   node-controller                      1         1d
kube-system   persistent-volume-binder             1         1d
kube-system   pod-garbage-collector                1         1d
kube-system   pv-protection-controller             1         1d
kube-system   pvc-protection-controller            1         1d
kube-system   replicaset-controller                1         1d
kube-system   replication-controller               1         1d
kube-system   resourcequota-controller             1         1d
kube-system   service-account-controller           1         1d
kube-system   service-controller                   1         1d
kube-system   statefulset-controller               1         1d
kube-system   storage-provisioner                  1         1d
kube-system   token-cleaner                        1         1d
kube-system   ttl-controller                       1         1d

As you can see, there are tons of control plane components with their own service accounts each and the infamous default service accounts, which you shouldn't be using, always create a dedicated one.

If you're ever in doubt if a certain entity, that is, a user or a service account is permitted to carry out a certain action (like creating a secret), you can use the kubectl auth can-i command to check that, for example:

# let's create a dedicated namespace called secdemo:
$ kubectl create ns secdemo
kubectl create ns secdemo

# let's create a service account nsadmin:
$ kubectl --namespace=secdemo create sa nsadmin
serviceaccount/nsadmin created

# checking if that service account is allowed to create secrets:
$ kubectl --namespace=secdemo auth can-i create secrets \ 
          --as=system:serviceaccount:secdemo:nsadmin
no

# let's give the service account nsadmin the permissions:
$ kubectl --namespace=secdemo create rolebinding nsadmin \
          --clusterrole=admin \
          --serviceaccount=secdemo:nsadmin 
rolebinding.rbac.authorization.k8s.io/nsadmin created

# … and now the service account nsadmin is allowed to 
# create secrets in the namespace secdemo:
$ kubectl --namespace=secdemo auth can-i create secrets \ 
          --as=system:serviceaccount:secdemo:nsadmin
yes

OK, that was it and if you want to learn more about RABC, I recommend to watch this awesome KubeCon 2017 talk:

And if you want some more info on RBAC usage, check out:

Thanks for checking in here and see you around some time soon.

Blog

On defaults in Kubernetes RBAC

Michael Hausenblas

Join Our Newsletter. No Spam, Only the good stuff.

Related