On defaults in Kubernetes RBAC
Tags: rbac, authorization, kubernetes, security
Published: 2018-11-11 17:33:19

---
title: On defaults in Kubernetes RBAC
published: true
description: Reviews and discusses default RBAC settings in Kubernetes
tags: rbac,authorization,kubernetes,security
cover_image: https://thepracticaldev.s3.amazonaws.com/i/v9u2n034340ol4abfv9n.png
canonical_url: https://dev.to/mhausenblas/kubernetes-rbac-defaults
---

In Kubernetes, the Role-Based Access Control (RBAC) method defines a number of [default roles and bindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-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](https://github.com/liggitt/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](https://itnext.io/the-abc-of-kubernetes-access-control-e7d280af5c88).

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:

{% youtube Nw1ymxcLIDI %}

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

- [A Read Only Kubernetes Dashboard](http://blog.cowger.us/2018/07/03/a-read-only-kubernetes-dashboard.html) 
- [Kubernetes and RBAC: Restrict user access to one namespace](https://jeremievallee.com/2018/05/28/kubernetes-rbac-namespace-user.html)
- [kubectl in action—RBAC](https://mhausenblas.info/kubectl-in-action/#rbac)

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