Security is key. Learn the concepts and tools needed to secure Kubernetes for applications. Click here to get started.


No results found.

Lesson 58:12

Kubernetes RBAC Concepts

In this course we'll cover the basics of Kubernetes RBAC. This is a Concepts based lecture that will show off of Authorizing users/services to leverage Kubernetes Resources.


Tim Carr

Tim Carr is a Product Line Manager at VMware and a member of the Heptio acquisition.

View Profile


Download Transcript

Hi, I’m Timmy Carr. I’m a cloud-native architect with VMware. Today we’re going to talk just a little bit about RBAC and our Kubernetes clusters. Now RBAC allows us to control what operations users or groups can execute on our cluster. They do so by leveraging native Kubernetes objects, namely roles and role bindings, which are names based. Then cluster roles and cluster role bindings, which are non-names based.

These roles and role bindings, and cluster roles and role bindings, really take the following approach to achieving the role based access control end goal. They use a subject which would be, in my case if I’m using my cube config file, would be a user with the cube config file, and that’s me. They take then the operation, for example, if I’m trying to get pods, that operations that get that verb. Then finally they’re talking to API resources, and those API resources could be pods, it could be deployments, services, secrets, namespaces, any kind of object that you’re normally trying to interact with within Kubernetes.

Once again, the subject works with an operation on the API resource, and we’re really trying to tie those three things together to build this comprehensive RBAC story that’s built into Kubernetes. Now to do that, we actually have to tie together leveraging a role, those API resources and operations, with a role binding. And that role binding simply says the role, meaning the API resources that we can talk to, and the operations that we can take on those API resources, needs to be linked to that subject. In my case, maybe it’s subject Timmy Carr trying to access the cluster.

Okay. Let’s dive into the cluster to show a little bit more about how this works in real life. I’m running the Prometheus operator on my cluster, and my cluster itself actually has a role in a role binding from that Prometheus operator that we can look a little bit more into. If we do, k get role, and just quickly you can see there’s the Prometheus k8 object. And if we do an, -o yaml, that will show us what that object is actually looking like on our cluster.

You can see it’s of kind role. You can see some annotations here. This is looking very typical for any sort of Kubernetes sort of object. You can see the name, and then the name space is in the default name space, in this use case. You can see that it is attempting to work with services, endpoints, and pods. And with the services, endpoints, and pods from all API groups. This is a wild card there. You can either get, listen, or watch those services, endpoints, or pods.

Now once again, jumping back to the presentation, you can see here in the presentation that that role has to tie together the operations and the API resources. Now that we’ve done that, we’ve built that role, we need to tie that role back to some subject. In the case of the Prometheus operator here, there is that role binding, which does that. Let’s have a look at that role binding.

So, k get rolebinding, and you can see that there’s a Prometheus k8 role binding. Okay, great. Let’s have a look at that. That role binding you can see, is first of all of kind role binding. It is in the default namespace, it’s named k8. This is all looking very similar to other sorts of objects that we would have in our cluster. It’s got this thing called a roleRef, and this tells it of kind role and names it here. The subject itself says kind of subject ServiceAccount. So this is a service account that it’s referencing that’s created on our cluster, and that service account name is called prometheus-k8, and that is in the name space monitoring.

Okay. We’re binding this role to a named Prometheus k8 service account in the namespace monitoring. Right. If we were to simply do, k get ServiceAccount, namespace monitoring, we would see that yes, there is indeed a Prometheus k8 service account that exists there.

Now in talking about this, what we’ve really talked about at this point is a role and role binding. It should be noted that when working with a role, the role is a names based object, meaning that it’s giving access within that namespace. And that role binding itself is actually giving access to that names based object as well. We can show this by doing, k api-resources, right? Everything’s always here for us in the Kubernetes cluster, to see what’s up. So, k api-resources, shows us, in fact if we were to look at, here they all are, cluster role. If you can see role, this last column here is, is it names based? In fact the role is names based. So is the role binding.

There are these other two objects called cluster roles and cluster role binding. The typical pattern that we see is we typically see a role and a role binding used to give access to a subject, to something that is within a certain namespace. A cluster role and a cluster role binding are just a little bit different. Cluster roles exist cluster wide, and cluster role bindings are used to grant permissions at the cluster level in all namespaces. For example, we could use a role binding to reference a cluster role, and in doing so, grant permissions to a namespace names based resource within the role bindings namespace. That’s a lot to say there.

But basically, once again we’re thinking about granting permissions on the names based resource within the role bindings namespace. Now the cluster role binding can also be used to grant permissions at the cluster level in all namespaces, right? The nuance and the way this may be different is, I may have a cluster role, right? I would then use a role binding to like, and maybe that cluster role is very repeatable, right? I may need to do that to grant a developer access to logs in their namespace, and I would do that for multiple developers. In that case, I would use that role binding over and over. The cluster role binding is more of an administrative function that would be used broadly across cluster.

So I’d like to thank you for this brief overview, and thank you for joining me on this brief overview today. We’ll see you in the next video.

Have questions about the material in this lesson? We’ve got answers!

Post your questions in the Kubernetes community Slack. Questions about this lesson are best suited for the #kubernetes-security channel.

Not yet a part of the Kubernetes Slack community? Join the discussion here.

Have feedback about this course or lesson? We want to hear it!

Send your thoughts to

Lesson Complete

Advancing to the next lesson in 5 seconds…

Next Lesson

Share Lesson