Kubernetes Simplified: RBAC basics
Explain like I’m 5
A Role is like being a Knight. There can be many Knights. When someone is knighted, the act of knighting is a role binding.
Explain like I’m 25
Role Based Access Control (RBAC), in Kubernetes, is a way to allow the system to answer the question:
Can (subject) (verb) (object)?
Subject: this can be a user , group or service-account
Verb: this can be create, get, list, update, delete, etc.
Object: this is K8s api-resource objects like pod, deployment, namespace, etc.
Why do we need it?
You have multiple people on your team, and everyone wants to access this one Kubernetes cluster. Each person on the team has different responsibilities and each person needs a level of isolation and security from one another. You do not want one person from accidentally interfering with other person’s work on the cluster. Thinking of about differences between developers, operators, cluster administrators, etc., there is a wide variety of reasons why you want to slice your Kubernetes cluster based on different roles and different capabilities. RBAC is the way you can restrict who can access what within a Kubernetes cluster.
A Role in RBAC defines a notion of verb (action), i.e.: get, list, etc., and a set of nouns, i.e: pods, secrets, etc.. So, a Role defines what you can do to a set of resources. But by itself, the role doesn’t grant any permissions, because we haven’t associated the role with anyone who might make the API calls. And that’s where a binding comes into play. So, a Role Binding is just a mapping between a user or a service account, and a particular role, i.e.: cluster-admin. A user can have multiple roles. And you can also use groups, and often times that’s a better way to manage RBAC is via groups, i.e: dev-team, admin-team. You can associate dev-team with a particular role. And that way if a new developer joins or leaves the team, they can be added or removed from the dev-team group and they will gain or lose to those particular privileges.
What is difference between ClusterRole and Role?
Within Kubernetes, there is two different types of resources. You can find which resources are what scoped by using kubectl api-resources -o wide. There is namespaced resources, for example a pod, a service. There is also cluster resources, for example, . Therefore, ClusterRoles define verbs on cluster scoped resources, and Roles define verbs for namespaced scoped resources.
What are Bindings and what is the difference between ClusterRoleBindings and RoleBindings?
In our ELI5 analogy, we explained that the process of getting knighted is analagous to a Role Binding. So, a Role Binding is grants a Role to a subject. There is two different types of role bindings you can have. One is ClusterRoleBindings, which provides you with permissions for the entire cluster. It can provide you permissions for cluster resources, as well as it provides you with permissions for resources within any namespace in a cluster. ClusterRoleBindings are very powerful, and you want to be very careful of how you apply them because they apply not only to any existing namespaces, but to any future namespaces that you might create as well. There is also RoleBindings, and they provide privileges within the context of a particular namespace. Obviously, ClusterRoleBinding is a cluster level object, and RoleBinding is a namespaced level object.
Combinations of Roles and Role Bindings
There is three different combinations of Roles and Role Bindings you can have with RBAC
ClusterRole + RoleBinding
Role + RoleBinding
ClusterRole + ClusterRoleBinding
Warning: this should be granted extremely limited, as it is equivalent to God mode in your cluster (depending on the Role defined). Always follow the least-privileges principle, assign only the permissions necessary.
TLDR
A Role defines what you can do to a set of resources. A Role Binding grants a Role to a subject. ClusterRoles are defined globally, while Roles are defined locally. ClusterRoles can be either granted globally via ClusterRoleBindings or granted locally via RoleBindings. Roles can only be granted locally via RoleBindings.
Heroic Links:
Jordan Liggitt KubeCon 2017 Talk on Effective RBAC
Brendan Burns Azure Kubernetes Series
