Exploring the RBAC Authorization

Explore different components of the RBAC authorization.

The RBAC Components

Managing Kubernetes RBAC requires knowledge of a few elements. Specifically, we should learn about Rules, Roles, Subjects, and RoleBindings.


A Rule is a set of operations (verbs), resources, and API groups. Verbs describe activities that can be performed on resources that belong to different API Groups.

Currently supported verbs are as follows:

Verb Description
get Retrieves information about a specific object
list Retrieves information about a collection of objects
create Creates a specific object
update Updates a specific object
patch Patches a specific object
watch Watches for changes to an object
proxy Proxies requests
redirect Redirects requests
delete Deletes a specific object
deletecollection Deletes a collection of objects

Permissions defined through Rules are additive. We cannot deny access to some resources. For example, if we want to allow a user only to create objects and retrieve their information, we’d use the verbs get, list, and create. A verb can be an asterisk (*) and so allow all verbs (operations).

Verbs are combined with Kubernetes resources. For example, if we want to allow a user only to create Pods and retrieve their information, we’d mix get, list, and create verbs with the pods resource.

The last element of a Rule is the API group. RBAC uses the rbac.authorization.k8s.io group. If we switch to a different authorization method, we need to change the group as well.


A Role is a collection of Rules. It defines one or more Rules that can be bound to a user or a group of users.

The vital aspect of Roles is that they are applied to a namespace. If we want to create a role that refers to a whole cluster, we use ClusterRole instead. Both are defined in the same way, and the only difference is in the scope (namespace or an entire cluster).


The next piece of the authorization mechanism is Subjects: Subjects define entities that are executing operations. A Subject can be a user, a group, or a service account.

A user is a person or a process residing outside a cluster. A service account is used for processes running inside Pods that want to use the API. Since this chapter focuses on human authentication, we won’t explore them right now. Finally, groups are collections of users or service accounts. Some groups are created by default (e.g., cluster-admin).


Finally, we need RoleBindings:

As the name suggests, RoleBindings bind Subjects to Roles.

Since Subjects define users, RoleBindings effectively bind users (or groups or service accounts) to Roles and give them permissions to perform certain operations on specific objects within a namespace. Just like Roles, RoleBindings have a cluster-wide alternative called ClusterRoleBindings. The only difference is that their scope is not limited to a namespace, but applied to a whole cluster.

Get hands-on with 1200+ tech skills courses.