Fine‑Grained Permissions in Rancher: A Practical Guide to RBAC for Multi‑Tenant Clusters

Why RBAC Matters in a Multi‑Tenant Rancher Environment

When a single Rancher instance manages dozens of Kubernetes clusters, the risk of accidental or malicious changes grows with each user you add. Role‑Based Access Control (RBAC) lets you lock down what each person can see or modify, keeping the blast radius small. Rancher exposes the same Kubernetes RBAC objects—ClusterRole, Role, ClusterRoleBinding, and RoleBinding—through its UI and CLI, but the UI can still hide subtle mistakes.

Mapping Kubernetes RBAC into Rancher

Rancher’s RBAC layer sits on top of the underlying Kubernetes cluster. You can:

• Define a ClusterRole that grants permissions across all namespaces.
• Bind that role to a user group with a ClusterRoleBinding.
• Use the UI to generate the YAML, then export it for review.

Because Rancher can integrate with external identity providers (OIDC, LDAP), you can map an LDAP group directly to a ClusterRoleBinding without manually editing the YAML each time.

Creating a View‑Only Role for All Namespaces

Suppose you want a group called read-only-users to see every namespace and workload but not modify anything. The following steps illustrate the process.

1. In the Rancher UI, navigate to Security > Roles and click Create Role.
2. Choose Cluster‑wide and select the View template. Rename the role to view-all-namespaces.
3. Export the generated YAML:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: view-all-namespaces
rules:
- apiGroups: ["", "apps", "batch", "extensions"]
  resources: ["pods", "deployments", "services", "configmaps", "secrets", "namespaces"]
  verbs: ["get", "list", "watch"]

Next, bind the role to the group:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-only-users-binding
subjects:
- kind: Group
  name: read-only-users
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view-all-namespaces
  apiGroup: rbac.authorization.k8s.io

Replace read-only-users with the actual group name from your identity provider.

Practical YAML Example

Below is a ready‑to‑apply manifest that you can copy into a file called view-all.yaml and apply with kubectl. The example assumes you are already authenticated against the target cluster.

# Apply the role and binding
kubectl apply -f view-all.yaml

# Verify the role exists
kubectl get clusterrole view-all-namespaces -o yaml

# Verify the binding
kubectl get clusterrolebinding read-only-users-binding -o yaml

After the binding is in place, log in as a user from the read-only-users group and run:

kubectl auth can-i get pods --all-namespaces --as=system:serviceaccount:default:demo
# Expected output: yes

If the command returns no, the binding is not active or the user is not part of the group.

Trade‑offs & Common Pitfalls

• Over‑permissive bindings: A ClusterRoleBinding attached to system:authenticated grants everyone in the cluster that role. Always target specific groups.
• Legacy roles: Rancher’s default roles change between major releases. Keep your custom roles up‑to‑date or migrate them when upgrading.
• Namespace isolation: If you later need per‑namespace restrictions, replace the cluster‑wide role with a Role and bind it to each namespace individually.
• Testing: Before deploying to production, apply the manifest to a test cluster and run kubectl auth can-i for each critical action.

Next Steps

1. Integrate your identity provider so that group membership automatically maps to RBAC bindings.
2. Use Rancher’s Export feature to keep a version‑controlled copy of your RBAC manifests.
3. Consider leveraging kubectl auth reconcile to audit and align actual permissions with your defined roles.
4. Document the role hierarchy in your team’s playbook to avoid accidental privilege escalation.