The Kubernetes Series - User and Cluster Roles

(Photo by Kimson Doan on Unsplash)

The previous post concerned SSL/TLS Certificates in Kubernetes. Now let's have a look at user roles and groups.

Authorisation Mode

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 --authorization-mode=RBAC.

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;

kubectl api-resources

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

Conclusion

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.