How does RBAC work in Kubernetes?
Tags: kubernetes, rbac
Published: 2022-05-24 05:46:38

Before diving into Kubernetes, let's take discuss how you'd grant access to resources.

_For example, how would you authorize access to apps?_

**The simplest idea is to assign permissions to users.**

Mo is an admin and can do anything.

Alice is a dev and has read-only access.

![Granting permissions to users directly](https://res.cloudinary.com/uasabi/image/upload/v1653295529/threads/rbac-2.png)

This authorization system works but has a limitation: **you have to re-assign permissions every time you add users.**

And worse, all permissions are duplicated.

If you have to remove write access to all users, you have to edit all of them.

_What's the alternative?_

![Permissions are duplicated when you grant them directly to users](https://res.cloudinary.com/uasabi/image/upload/v1653295529/threads/rbac-3.png)

**Instead of assigning permissions to users directly, you could assign them to a generic profile.**

Let's create a profile "admin" and assign all the permissions.

And you could have a "dev" with read-only.

![Assigning permissions to roles](https://res.cloudinary.com/uasabi/image/upload/v1653295529/threads/rbac-4.png)

Finally, you could assign those generic profiles to users.

Mo is the "admin" and Alice a "dev".

If there's a new dev joining the team, you can assign the "dev" profile again.

**Those profiles are usually called Roles.**

And that's how you have Role-Based Access Control (RBAC).

![Role-Based Access Control](https://res.cloudinary.com/uasabi/image/upload/v1653295529/threads/rbac-5.png)

Now that we've discussed how to grant permissions, it's time to look at the resources.

_What are you giving access to?_

**[In Kubernetes, we grant access to API endpoints.](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#api-overview)**

Example: you can list Pods, but not Secrets.

Or: you can use the default namespace, but not kube-system.

![Granting access to API endpoints in Kubernetes](https://res.cloudinary.com/uasabi/image/upload/v1653295529/threads/rbac-6.png)

_What about users?_

In Kubernetes, Roles can be assigned to external [users (humans!) or bots (applications inside the cluster).](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#referring-to-subjects)

You can also have groups that are a mix of both.

![RBAC has two kinds of users: Users, Bots. There are also groups (a mix of both)](https://res.cloudinary.com/uasabi/image/upload/v1653295529/threads/rbac-7.png)

So let's recap:

1. You have users (humans, bots, groups).
2. You create roles to grant permissions to the API endpoints.
3. You link roles to users.

The last step is called binding, and it's usually done through another object called **RoleBinding that links identities to roles.**

![Granting permissions to users with RBAC](https://res.cloudinary.com/uasabi/image/upload/v1653295529/threads/rbac-8.png)

_There's one thing to remember, though._

**Roles and RoleBindings are created in a namespace, and they grant access to resources in the current namespace.**

What happens when you want to grant access to global resources, such as Nodes or Persistent Volumes?

It'd be great if there were a way to define a profile as global instead of being scoped to a namespace.

Well, you just invented the **ClusterRole — a global role that applies to the entire cluster.**

To link an identity to a global role, [we use a ClusterRoleBinding.](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding)

![A ClusterRole grants permissions to the entire cluster.](https://res.cloudinary.com/uasabi/image/upload/v1653295529/threads/rbac-9.png)

_What happens when you link a "standard" ClusterRole to a RoleBinding?_

_Is it even possible?_

Yes.

The user will have all the permissions from the ClusterRole but scoped in the current namespace of the RoleBinding.

![Linking a ClusterRole with a RoleBinding](https://res.cloudinary.com/uasabi/image/upload/v1653295529/threads/rbac-10.png)

Lastly a few useful kubectl commands that I find helpful:

- **[User-impersonation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation)** with "kubectl <verb> <resource> --as=jenkins".
- **Verifying API access** with "kubectl auth can-i <verb> <resource>".

You can also combine them.

This thread is a very short summary of Arthur's article on the @learnk8s blog: https://learnk8s.io/rbac-kubernetes.

If you want to dig deeper into Kubernetes and RBAC, make sure to check it out.

And finally, if you've enjoyed this short post, you might also like the [Kubernetes workshops that we run at Learnk8s](https://learnk8s.io/training) or this collection of past Twitter threads https://twitter.com/danielepolencic/status/1298543151901155330.

Until next time!