Skip to main content
In this guide, we explore Role-Based Access Controls (RBAC) in Kubernetes, including how to create and manage roles and role bindings effectively. RBAC provides a robust mechanism for managing access to resources within a Kubernetes cluster.

​
Creating a Role

A Role in Kubernetes encapsulates a set of permissions for resources within a namespace. To create a role, define a role object in a YAML file with the following essential components:
  • Set the API version to rbac.authorization.k8s.io/v1
  • Specify the kind as Role
  • Provide a metadata name (for example, “developer”)
  • List the rules that define the API groups, resources, and permitted verbs (actions)
For resources within the core group, leave the API groups field blank. For resources in other groups, specify the group name explicitly. Below is an example YAML configuration that creates a “developer” role. This role allows actions such as listing, getting, creating, updating, and deleting pods, and includes an extra rule to create ConfigMaps:
Create the role using the following command:
Both roles and role bindings in Kubernetes are namespace-scoped. In this example, the developer role applies only to the default namespace. To apply a role in another namespace, add the namespace field within the metadata section of your YAML file.

​
Creating a Role Binding

After defining a role, bind it to a specific user using a RoleBinding. A role binding connects a user to a role within a namespace, thereby granting the user the permissions defined in that role. Below is an example YAML configuration that creates a role binding named “devuser-developer-binding”. This binding assigns the “developer” role to the user dev-user:
Create the role binding using the command:

​
Viewing and Verifying Roles and Bindings

​
Listing Roles and Role Bindings

You can verify that your roles and role bindings have been created correctly using the kubectl commands below:
This command outputs a list of roles, for example:
Similarly, list the role bindings:
Output example:

​
Describing Specific Resources

To get detailed information about a specific role, use:
Example output:
Similarly, for a detailed view of a role binding, run:
Example output:

​
Verifying User Permissions

Use the kubectl auth can-i command to verify if a user has permission to perform a specific action on a resource. For instance, to check if you can create deployments or delete nodes, execute:
If you are an administrator wishing to test permissions for another user without switching accounts, use the --as flag. For example, to check if dev-user can create deployments or pods, run:
Remember, you can also include the --namespace flag to specify the namespace for these commands.

​
Restricting Access to Specific Resources

Sometimes it’s necessary to restrict a role’s permissions to only specific resource instances. For example, if a user should only have access to pods named “blue” and “orange”, you can utilize the resourceNames field in the role’s rule:
This configuration ensures that the user can only interact with the specified pods.

​
Conclusion

This guide covered the essentials of Kubernetes Role-Based Access Controls, including creating roles, binding them to users, and verifying permissions. For more detailed information on Kubernetes RBAC, refer to the official Kubernetes Documentation. Happy securing your Kubernetes clusters!

Watch Video