Rancher RBAC allows you to grant granular permissions to users and groups, but the most powerful way to leverage it is by assigning roles not just to users, but to entire projects and namespaces.
Let’s see this in action. Imagine you have a dev project in Rancher, and within that project, a staging namespace. You want to give your developers group read-only access to everything in the staging namespace, but not the rest of the dev project.
First, ensure you have your users and groups defined in Rancher (or synced from an external provider like Active Directory). For this example, let’s assume a group named developers.
Now, navigate to your dev project in Rancher. On the project’s dashboard, you’ll see a section for "Roles" or "Permissions." Click on "Add Role Assignment."
Here’s where it gets interesting. You’ll be prompted to select a user or group, and then a role. Crucially, you can scope this role assignment down to a specific namespace.
Select the developers group. For the role, choose a built-in role like Read-Only. Then, instead of assigning it to the entire project, click the option to scope it to a namespace. A dropdown will appear, listing the namespaces within the dev project. Select staging.
What just happened? Rancher didn’t just give developers read-only access to everything in the dev project. It specifically granted them Read-Only permissions only within the staging namespace. They can see pods, deployments, services, etc., in staging, but if there were other namespaces like testing or prod within dev, they would have no visibility into those.
This mechanism is incredibly powerful for enforcing the principle of least privilege. You can create distinct projects for different environments (dev, staging, prod) and then within those projects, create namespaces for specific applications or teams. Then, you can assign roles at the namespace level, ensuring teams only have access to the resources they absolutely need.
Consider a scenario where you have a ci-cd project. You might have a namespace named build-agents within it. You could assign a custom role that allows only the creation and deletion of pods (but not viewing or modifying other resources) to your CI/CD system’s service account only within that build-agents namespace. This prevents the CI/CD system from accidentally or maliciously affecting other cluster resources.
The underlying mechanism is that Rancher translates these project/namespace-scoped role assignments into Kubernetes Role or ClusterRole and RoleBinding or ClusterRoleBinding objects. When you assign a role to a namespace, Rancher creates a RoleBinding in that specific namespace. If you assign a role to a project (which inherently contains multiple namespaces), Rancher might create multiple RoleBinding objects, one for each namespace in the project, or a ClusterRoleBinding if the role itself is cluster-scoped and you’re granting it across all namespaces in the project. The key is that the RoleBinding objects have a namespace field set, limiting their effect to that particular namespace.
Most people understand assigning roles to users, but the ability to assign roles to projects and namespaces is the real game-changer for managing complex Kubernetes environments at scale. It allows you to delegate administrative responsibilities and enforce security policies with precision, without needing to manage individual user permissions for every single namespace.
The next step is to explore creating custom roles to define even more granular permissions tailored to specific team needs.