[MUSIC] >> Hi, I'm Brendan Burns from Microsoft Azure and I'm going to talk about Role Based Access Control in Kubernetes.
Let's see about why you're interested in access control.
Well, obviously, you have multiple people on your teams and they're accessing your Kubernetes cluster.
But each of these people may need to have some amount of security from one another.
At the simplest level, you simply don't want this person interfering with the other person accidentally.
For example, one developer might accidentally delete someone else's work or gain visibility into a project that's being developed that maybe secret.
There's a wide variety of reasons why you want to slice apart your Kubernetes into a place where user one can see and a place for user two can see, and have them not be able to see into each other's work.
When you think about the differences between developers and operators, cluster administrators, it becomes even more clear that there are different capabilities that need to be associated with different types of roles within that Kubernetes cluster, and that's where the notion of RBAC or role-based access control comes into play.
RBAC in Kubernetes is the way that you restrict who can access what within the cluster.
So in order to understand how RBAC works in Kubernetes, it's important to understand how role-based access control works in general.
The role in role-based access control defines a notion of a verb something like get or a list, and a set of nouns, something like pods, volumes, etc.
So a role defines what you can do to a set of resources.
This is a resource within Kubernetes just like everything else.
So this is a restful resource and there's a number of them that are predefined, and you can also create them yourself using a YAML file.
So you can represent any arbitrary set of privileges onto the resources within the Kubernetes cluster.
But by itself, the role doesn't actually grant any permissions, because we haven't associated this role with anyone who might make API calls, and so that's where a binding comes into play.
So you can create a role binding which is basically a mapping between a person, let's say me, and a particular role, let's say cluster admin.
So the role binding takes these two pieces together and therefore, I have the privileges defined in this role.
Now, I can have multiple roles.
I might get edit as well or any number or custom role that's been designed.
I can have access to any number of roles, and you can also use groups.
Oftentimes, actually, this is a much better way to manage things if you define a group.
For example, the dev team, you can associate that dev team with a particular role.
In that way, anyone who joins that team or is removed from that team either gains access or loses access to those particular privileges.
Now within Kubernetes, there's actually two different kinds of resources.
There are namespace resources and there are non, there are cluster resources.
An example of a cluster resource would be something like a custom resource definition that is defined for the entire cluster.
An example of a namespace resource might be something like a service or a pod, they exist within a namespace.
These namespaces also become the scopes for resource control.
So you can actually say not only does somebody have access to pods, but maybe they only have access to pods under the namespace "my-team", so you can limit, and then "your-team".
I might have access to pods in my team but I won't have access to pods in your team.
The way that you do this is by creating a role binding within this namespace.
So there's two different types of role bindings that you can create.
One is the cluster role binding, and obviously, by its name, a cluster role binding provides you with permissions for the entire cluster.
It can provide you with permissions for cluster resources and it can also provide you with permissions for resources within any namespace within a cluster.
Obviously, cluster role bindings are very powerful, and you want to be careful with 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 are also role bindings and they provide privileges within the context of a particular namespace.
So obviously, a cluster role binding is a cluster level object, a role binding is a namespace object.
So if for example, I have my "my-team" namespace, if I create a role binding here, that is a binding say to the edit role.
This provides me with the ability, if it is a role binding between edit and me, this provides me with access to editing within the context of this namespace, but not any other namespace.
So the fact that the role binding exists within the context of this namespace, defines the scope for that role binding.
If I instead gave myself a cluster role binding at the top level, it would provide me with access to binding, it would provide me with access to the entire cluster.
I definitely encourage people to check out all of the different roles that are predefined inside of Kubernetes.
There's a lot of them that can give you an idea and you can even use to build up your own access control, and take a deep look into how you want to manage the different roles inside of your cluster so that you can provide a secure cluster where two developers or two operators can't step on each other's toes, see each others secrets, or otherwise, interfere with one another.
[MUSIC]