Challenge ·Medium

Isolate a Team with Quotas and RBAC

Carve out a namespace for a team, cap its resource consumption with a ResourceQuota, and grant a user scoped read-only access with a Role and RoleBinding. These are the native Kubernetes primitives Rancher Projects and roles build on.

Rancher Projects and its built-in roles are convenience layers over primitives that already exist in Kubernetes: namespaces, resource quotas, and RBAC. Understanding those primitives is what lets you reason about who can do what once Rancher is in the picture. In this challenge you will set up isolation for a single team by hand.

Work from the dev-machine terminal (its kubectl is already pointed at the cluster). You will create a namespace for a frontend team, cap its resource usage, and give a user named alice read-only access to it - and only it.

Step 1: Create the Team Namespace

Create a namespace called team-frontend.

Step 2: Cap Resource Consumption

Add a ResourceQuota to team-frontend that limits at least the number of pods and the total CPU requests. This stops one team from exhausting the cluster.

Hint 1

A ResourceQuota object with a spec.hard map does the job. Include both a pods count and a requests.cpu value. The tutorial for this lesson shows the field layout.

Step 3: Define a Read-Only Role

Create a Role in team-frontend that grants only read verbs (get, list, watch) on workload resources. It must not grant any write verbs.

Hint 2

Keep the verbs list restricted to get, list, and watch. Any of create, update, patch, delete, or the * wildcard will make the role fail the read-only check.

Step 4: Bind the Role to alice

Create a RoleBinding that binds your read-only Role to the user alice. Then confirm that alice can read but cannot write.

Hint 3

The RoleBinding subjects entry should be kind: User with name: alice, and its roleRef should point at the Role you created. You can check the result yourself with kubectl auth can-i ... --as alice.