/
Write
Start a team blog
NEW ✨
Start a team blog, invite your team, and start publishing.
How does RBAC work in Kubernetes?

How does RBAC work in Kubernetes?

Daniele Polencic's photo
Daniele Polencic
·May 24, 2022·

3 min read

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

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

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

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

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.

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

What about users?

In Kubernetes, Roles can be assigned to external users (humans!) or bots (applications inside the cluster).

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)

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

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.

A ClusterRole grants permissions to the entire cluster.

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

Lastly a few useful kubectl commands that I find helpful:

  • User-impersonation with "kubectl --as=jenkins".
  • Verifying API access with "kubectl auth can-i ".

You can also combine them.

This thread is a very short summary of Arthur's article on the @learnk8s blog: 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 or this collection of past Twitter threads twitter.com/danielepolencic/status/12985431...

Until next time!