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-adminandadmingive read-write access to all (respectively many) resources. In general, if you want to make someone superuser or cluster root, then use thecluster-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 eithercluster-adminandadminwith 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 betweencluster-adminandadminis that the latter is a little more restrictive when it comes to certain resources such as the namespaces themselves. - The
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. - The
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.
Top comments (0)