# Reflection: Permissions Should Reflect What a Workload Actually Needs

You just configured real ServiceAccounts and RBAC rules. Take a few minutes to connect this to
production security practice.

## Reflection questions

1. Before this module, would you have thought twice about a workload's ServiceAccount having
   broad, unused permissions "just in case"? Has that changed?
2. If a workload with cluster-admin-equivalent RBAC access is ever compromised (a vulnerable
   dependency, a supply-chain issue), what's the realistic blast radius compared to one scoped
   to exactly what it needs?
3. How would you discover, on a real cluster you didn't build, whether any ServiceAccount has
   more access than it actually uses?

## Real Ops takeaway

**RBAC over-permissioning is a silent, cumulative risk.** Unlike a misconfigured probe or a
crashing Pod, an over-broad Role doesn't cause a visible symptom on a healthy day — it just sits
there as unused risk until the one day a workload using it is compromised. This makes RBAC
review a discipline that has to be practiced deliberately, not one that gets forced on you by
an obvious failure.

**Least privilege is a default you set once, not a fix you apply after an incident.** Every
example in this module started from "grant nothing, add exactly what's needed" rather than
"grant broadly, restrict later" — the second approach almost never actually happens once
something works, because there's no pressure forcing the cleanup.

This module is complete. Continue to the next module.

## Instructor Notes

**Discussion questions for a live classroom:** question 3 is a good one to leave partially open
— acknowledge that real answers involve tooling beyond plain `kubectl` (RBAC audit tools) that
this course doesn't build hands-on, while still reinforcing that the QUESTION itself is the
right one to ask.

**Approximate timing:** 8 minutes live discussion; 5 minutes self-paced writing.

**Optional extension:** ask students to identify one ServiceAccount permission from earlier in
ROOT_ (any Lab so far) that, in a real production system, they'd want to double-check was
actually necessary.