Deep Dive into Kubernetes Authorization

Why Authorization?

As administrators of a Kubernetes cluster, we possess the ability to execute various operations such as adding or removing pods and nodes. However, when granting access to other users, it's crucial to avoid providing unrestricted permissions. For instance, it would be inappropriate to grant a developer the capability to delete nodes. This is where authorization becomes essential, and Kubernetes provides a solution through role-based access control (RBAC) system

Roles in Kubernetes

A Role is a Kubernetes resource type that defines a specific set of permissions within a designated namespace.

To create a Role, it's important to understand Kubernetes resources are categorized into API groups. API groups facilitate the organization and management of related resources within Kubernetes. When assigning permissions to a resource, we specify its API group in the rules section of the YAML file. Additionally, we define the actions (verbs) that we wish to permit on the resource within the verb section. Here is an sample Yaml file to create an role named developer

For the core API group, there's no need to explicitly mention the group name. That's why apiGroups is not specified. After creating the role, we can verify its creation status as well.

RoleBinding: Attaching Roles to Users

After creating a role, we must attach it to a user by creating a RoleBinding resource. Here is an example YAML file for this process.

After creating the RoleBinding, the user is assigned the role along with the permissions defined within that role.

To verify the permissions of the user, you can use the following command.

Even after taking these actions, a challenge persists with resources that are not namespaced, such as Nodes and PersistentVolumes . How do we set permissions for these resources, considering they are not associated with any namespace ?

To address this limitation, Kubernetes offers ClusterRoles. Unlike Roles, ClusterRoles are designed for cluster-wide resources and are not confined to any specific namespace.

Cluster Roles

ClusterRoles function similarly to Roles but are intended for cluster-wide resources. They are not associated with any specific namespace and provide permissions across the entire cluster . Here is an example YAML file

ClusterRoleBinding: Attaching ClusterRoles to Users

Once a ClusterRole is created, it must be attached to a user by creating a ClusterRoleBinding resource. Here is an example YAML file for this process:

In conclusion, Kubernetes robust role-based access control (RBAC) system, leveraging Roles for namespaced resources and ClusterRoles for cluster-wide resources, ensures secure and granular management of permissions within the cluster.