# Guided Exercise: Writing a Least-Privilege Role

Paper-and-thinking exercise before the Labs.

## The scenario

A monitoring agent needs to run inside your cluster. Its ONLY job is to periodically list Pods
and read their status, across the whole cluster, to report health metrics elsewhere. It never
needs to create, modify, or delete anything, and it never needs to touch Secrets, ConfigMaps, or
any object type other than Pods.

## Your task

1. Should this use a Role or a ClusterRole? Justify your answer based on scope.
2. Which verbs does it actually need? Which common verbs (create, update, delete, patch) should
   be deliberately left OUT?
3. Does it need access to Secrets? Why is it tempting to grant broader access "just in case,"
   and why should you resist that?
4. What would you check, using `kubectl auth can-i`, to CONFIRM your Role is exactly as narrow
   as intended before deploying it?

## A worked answer to check yourself against

1. **ClusterRole** (bound via a ClusterRoleBinding) — it needs to see Pods across the WHOLE
   cluster, not just one namespace, so a namespace-scoped Role can't satisfy the requirement.
2. **`get`, `list`, `watch`** on `pods` — read-only verbs only. Deliberately exclude `create`,
   `update`, `patch`, `delete` — this workload never legitimately needs to change anything.
3. No — it never touches Secrets, so it should get zero permission on them. The temptation to
   "just in case" grant broader access is exactly what least privilege exists to resist: every
   unused permission is pure risk with no corresponding benefit if this workload is ever
   compromised.
4. Run `kubectl auth can-i delete pods --as=<the ServiceAccount>` and confirm it returns `no` —
   and similarly check a Secrets verb returns `no` — proving the Role is bounded, not just
   assuming it from reading the YAML.

## Instructor Notes

**Facilitation:** Question 3 is the core judgment call this exercise is testing — push on WHY
"just in case" access is a real anti-pattern, not just point out that it is one.

**Approximate timing:** 10-12 minutes live with discussion; 10 minutes self-paced.

**Optional extension:** ask what would change about the answer if this monitoring agent later
needed to also restart crash-looping Pods automatically — a good check that students can reason
about incrementally expanding a Role's scope only as far as a genuinely new requirement demands.