Skip to main content
In this lesson, we dive into Kubernetes Role-Based Access Controls (RBAC) to help you manage permissions effectively. You’ll learn how to create roles, bind them to users, and verify permissions within a namespace.

​
Creating a Role

To define a role, create a YAML file that sets the API version to rbac.authorization.k8s.io/v1 and the kind to Role. In this example, we create a role named developer to grant developers specific permissions. The role includes a list of rules where each rule specifies the API groups, resources, and allowed verbs. For resources in the core API group, provide an empty string ("") for the apiGroups field. For instance, the following YAML definition grants developers permissions on pods (with various actions) and allows them to create ConfigMaps:
Create the role by running:
Both roles and role bindings are namespace-scoped. This example assumes usage within the default namespace. To manage access in a different namespace, update the YAML metadata accordingly.

​
Creating a Role Binding

After defining a role, you need to bind it to a user. A role binding links a user to a role within a specific namespace. In this example, we create a role binding named devuser-developer-binding that grants the user dev-user the developer role. Below is the combined YAML definition for both creating the role and its corresponding binding:
Create the role binding using the command:

​
Verifying Roles and Role Bindings

After applying your configurations, it’s important to verify that the roles and role bindings have been created correctly. To list all roles in the current namespace, execute:
Example output:
Next, list all role bindings:
Example output:
For detailed information about the developer role, run:
Sample output:
To view the specifics of the role binding:
Example output:

​
Testing Permissions with kubectl auth

You can test whether you have the necessary permissions to perform specific actions by using the kubectl auth can-i command. For example, to check if you can create deployments, run:
This command might return:
Similarly, to verify if you can delete nodes:
Expected output:
To test permissions for a specific user without switching user contexts, use the --as flag. Although the developer role does not permit creating deployments, it does allow creating pods:
You can also specify a namespace in your commands to verify permissions scoped to that particular namespace.

​
Limiting Access to Specific Resources

In some scenarios, you may want to restrict user access to a select group of resources. For example, if you have multiple pods in a namespace but only intend to provide access to pods named “blue” and “orange,” you can utilize the resourceNames field in the role rule. Start with a basic role definition without any resource-specific restrictions:
Then, update the rule to restrict access solely to the “blue” and “orange” pods:

​
Conclusion

This lesson provided an in-depth look at implementing Role-Based Access Controls in Kubernetes. You learned how to create roles and role bindings, verify permissions, and restrict access to specific resources. Practicing these exercises will enhance your grasp of RBAC and help you manage Kubernetes security effectively. For additional details on Kubernetes RBAC, refer to the Kubernetes Documentation and explore best practices for securing your clusters.

Watch Video

Practice Lab