Skip to main content
In this lesson, you’ll learn about role-based access control (RBAC) in Kubernetes. RBAC enables you to define roles with specific permissions and bind those roles to users or groups, ensuring secure and controlled access within your cluster. We’ll walk through creating a role, binding it to a user, verifying configurations, and restricting access to specific resources.

​
Creating a Role

A role in Kubernetes is defined in a YAML file that outlines the permitted actions under the following key elements:
  • apiVersion: Must be set to rbac.authorization.k8s.io/v1.
  • kind: Should be Role.
  • metadata.name: The name of your role (e.g., “developer”).
  • rules: A list describing the API groups, resources, and verbs (actions) that are allowed.
For example, to create a role that allows developers to manage pods and create ConfigMaps, use the following YAML:
After saving the YAML file (for instance, as developer-role.yaml), create the role with:
Roles and role bindings are namespaced. In the example above, the role is created in the default namespace unless you specify otherwise within the metadata.

​
Binding the Role to a User

To grant the permissions defined in the role to a user, you need to create a role binding. A role binding links a user (or group) to a role. The YAML for a role binding includes:
  • metadata.name: A unique name for the role binding (e.g., “devuser-developer-binding”).
  • subjects: The user, group, or service account to which permissions are granted.
  • roleRef: A reference to the role created previously.
Below is an example that binds the “developer” role to the user “dev-user”:
Create the role binding by running:

​
Verifying Roles and Bindings

To confirm that the role and its binding have been created successfully, you can list them using the following commands: List all roles in the current namespace:
Example output:
List all role bindings:
Example output:
To view detailed information about a specific role, use:
This command displays details such as allowed resources and permissions, for example:
Similarly, inspect the details of the role binding with:
The output might look like this:

​
Checking Permissions

You can verify if you or another user have access to particular resources using the kubectl auth can-i command. For example: To check if you can create deployments:
Example output:
To check if you have permissions to delete nodes:
Example output:
If you want to check permissions for a different user (like “dev-user”) without switching accounts, use the --as flag. For example, if the dev user has permission to create pods but not deployments, these commands will reflect that:
Remember, you can also specify the namespace with the --namespace flag if needed.

​
Restricting Access to Specific Resources

RBAC in Kubernetes allows you to fine-tune permissions at a granular level. Instead of granting permissions universally to a resource type, you can restrict them to specific resources using the resourceNames field. For example, to allow a user to interact only with pods named “blue” and “orange”, define the role as follows:
This configuration limits actions strictly to the specified pods.

​
Conclusion

In this lesson, we covered how to configure RBAC in Kubernetes by:
  • Creating a role with defined permissions.
  • Binding a user to that role using a role binding.
  • Verifying roles and permissions through kubectl commands.
  • Checking and testing user permissions.
  • Restricting access to specific resources for enhanced security.
For additional information on Kubernetes RBAC, consider reviewing the Kubernetes Documentation. Continue practicing by applying these concepts to secure your cluster effectively.

Watch Video

Practice Lab