RBAC is quickly becoming best-practice for protecting your Kubernetes cluster. With RBAC, it is possible to arrange access control to an advanced level in an orderly manner. Since Kubernetes 1.8 it is possible to use Role Based Access Control. Many providers of Managed Kubernetes Clusters have activated RBAC by default. Also at Cloudlets, RBAC is activated at Kubernetes by default. To make a good start with Kubernetes, it is crucial that you understand how RBAC works, why it is important to use RBAC and how to use it in practice.
Cloudlets make Kubernetes accessible to a broader audience. We do this by making it easy to setup a Kubernetes cluster, by offering useful tools that help you manage Kubernetes and by providing excellent support. We are aware that in our ambitions to making Kubernetes more accessible, we should under no circumstances compromise on security. That is why we will explain RBAC in easy-to-understand language.
What is RBAC for Kubernetes?
With Role Based Access Control, RBAC for short, you can manage permissions for users and applications to perform certain actions in your cluster. Before the introduction of RBAC, it was impossible to give users or applications limited access to your cluster. Either full access or no access at all were the only options. In many cases, it is desirable to work with roles. Every user who has assigned a certain role can perform the tasks that belong to that role. You can give access to your entire cluster or to namespaces in your cluster by means of a role. In addition, you define in a role which form of access you want to give: create, read, update, delete.
The use of RBAC is increasingly becoming the standard. Not only in Kubernetes, but also in many other areas, this form of access control is applied.
The basic concepts of RBAC
To work with RBAC it is important that you know the following basic concepts:
- Role and ClusterRole
- A role is a set of rules that determine the rights in the Kubernetes cluster. A role can relate to the entire cluster or to a namespace (a delimited part of the cluster). If there is a role with which rights are regulated to the entire cluster, then there is a ClusterRole.
- Roll binding
- A role can be assigned to users, applications or service accounts. You do that by applying a roll binding. Role binding can give access to a namespace, but also to your cluster. If your role binding relates to the entire cluster, then we speak of ClusterRoleBindings. Roll binding can be created easily with kubectl. Once the bindings are created, you can apply them to the resources in your cluster.
- Verbs
- The actions you can allow through RBAC are Verbs: create, delete, deletecollection, get, list, patch, update and watch.
- Resources
- An object within your cluster on which an action can be performed. Pod, deployment and namespace are examples of objects on which, if the right role has been assigned, you can perform an action.
Default ClusterRoles
If you have not previously worked with RBAC, implementing the right rules quickly becomes a complex and time-consuming activity. In order to be able to start the safety of your cluster relatively quickly and easily, Kubernetes comes with a different standard ClusterRole. It concerns the following roles that all control access to your entire cluster:
- admin
- The admin role allows you to give users and applications full access to resources within a namespace. Users and applications that have the admin role can read, modify and delete everything within the specified namespace.
- cluster-admin
- Similar to the admin role, with the important difference that the cluster admin at the highest level has all rights and therefore does not have to be bound in advance to specific resources on which actions must be carried out. The cluster-admin role gives you full access to all resources in the cluster.
- edit
- The edit role gives you rights to view and change a large part of the resources within a namespace. You can not change or delete resources to which this role is not linked.
- view
- The view role gives you read-only access, allowing you to see most of the resources within a namespace.
The above is a quick representation of the rights per standard role. Do you want to know all the details? You can get them via kubectl with the command kubectl describe cluster rolename.
Using RBAC with Kubectl & .yaml files
When you’re used to assign rights to specific users or accounts, you’ll have to change your way of working. When using RBAC, permissions are assigned to roles. These roles, in turn, apply to specific users or service accounts. This role defines all permissions within a cluster or namespace.
Assign clusterrole to a user or serviceaccount
Kubernetes comes with some pre-defined roles by default, as shown in the chapter above. If you want to assign permissions to view your cluster, you can do so by applying an existing view-role to a user or service account:
$ kubectl create rolebinding rolename-view --clusterrole view --user username
In the above command, we create a role binding with the name role name-view. That role binding applies the view-role to username. Instead of view you can choose a different (cluster) role. It is recommanded to give the role binding a recognizable name so you can easily adjust or withdraw the role at a later time.
Creating a new role
Do you want to create a role that gives access within a namespace? This can be done by executing a .yaml-file that specifies all characteristics that role should have. Below you’ll find an example of a .yml file that creates the role pod-reader is created. The pod-reader role gives access to the namespace default. With the role you get the permissions to get, watch and list resources in the cluster.
kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: default name: pod-reader rules: - apiGroups: [""] # "" indicates the core API group resources: ["pods"] verbs: ["get", "watch", "list"]