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,
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:
admingive read-write access to all (respectively many) resources. In general, if you want to make someone superuser or cluster root, then use the
cluster-admincluster-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
adminwith 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
adminis that the latter is a little more restrictive when it comes to certain resources such as the namespaces themselves.
editrole 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.
viewrole 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:
- A Read Only Kubernetes Dashboard
- Kubernetes and RBAC: Restrict user access to one namespace
- kubectl in action—RBAC
Thanks for checking in here and see you around some time soon.