The previous post concerned SSL/TLS Certificates in Kubernetes. Now let's have a look at user roles and groups.
Kubernetes includes different ways of authorising what users can do. These include;
- Node - Grants permissions to kubelets based on their assigned pods.
- ABAC - Attribute-based access control (ABAC).
- RBAC - Role-based access control (RBAC).
- Webhooks - A WebHook is an HTTP POST that occurs when some specified event happens.
To enable RBAC, start the apiserver with
We will be using RBAC for this post. To check what authorization modes are applicable to your cluster, run;
kubectl describe pod kube-apiserver-master -n kube-system
And check the --authorization-mode flag.
Creating User Roles & Bindings
User roles can be create like all other Kubernetes objects, so lets look at the YAML;
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: pod-reader rules: - apiGroups: [""] # "" indicates the core API group resources: ["pods"] verbs: ["get", "watch", "list"]
The pod-reader user role above allows its members to get, watch and list the pods running on your cluster. They are not allowed to create, update or delete pods. If you omit the namespace key, your roles will apply to the default namespace.
If you wanted to you could limit the roles to certain API groups too. You can view the available options on your cluster with;
To add a user to a Role, we need to bind it, like follows;
apiVersion: rbac.authorization.k8s.io/v1 # This role binding allows "Rik" to read pods in the "default" namespace. kind: RoleBinding metadata: name: read-pods namespace: default subjects: <-- add users here - kind: User name: Rik apiGroup: rbac.authorization.k8s.io roleRef: <-- add roles to bind to users here kind: Role <-- must be Role or ClusterRole name: pod-reader apiGroup: rbac.authorization.k8s.io
Create those to files and then view the newly created objects;
kubectl get roles && kubectl get rolebindings
Or view a particular Role;
kubectl describe role pod-reader
As a user, you can also check if you have access to a particular kube-apiserver resource with the following command;
kubectl auth can-i create pods
The user Rik above would see that they can not create pods.
The cluster administrators can check the permissions of a particular Role too, with;
kubectl auth can-i create pods --as Rik
Cluster Roles & Bindings
User roles applies to to objects created in namespaces, like Pods, ReplicaSets, Deployments, ect. But some resources belong to the cluster as a whole(and are thus not namespaced), like nodes, persistent volumes, CSRs, ect. You need to have a way to control who has access to these resources too.
Or you might want to assign a user roles for all namespaced resources on the cluster too, like allowing a dev to view all Pods.
That's where Cluster Roles come in.
Let's look at a cluster role definition file from the Kubernetes docs;
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: secret-reader rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"]
And now let's look at a binding;
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: secret-reader-binding subjects: - kind: User name: secrets-admin-rik apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io
Great stuff! In this post we covered how to create UserRoles and ClusterRoles, to control who gets access to what resources on our cluster.
The next post will cover how we manage access to container images.