Exercise 3: How Scoped RBAC Closes the base64 Gap From Chapter 1-7 — Possible Solution
====================================================================

What base64 encoding alone does NOT restrict:

Per `k8s1-7`, base64 is a reversible ENCODING, not encryption -- it
requires no key or password to decode, meaning "anyone with read
access to the Secret object... can trivially decode it back to
plaintext." Critically, base64 encoding itself does absolutely
NOTHING to control WHO is able to obtain that read access in the first
place -- it's purely about the FORMAT the value is stored in, not
about ACCESS to that stored value at all.

What RBAC specifically restricts:

Per this chapter, "a Role can specifically restrict get/list access on
Secret resources." This is an access-control mechanism operating at a
COMPLETELY DIFFERENT layer than encoding -- rather than changing what
FORMAT the Secret's value is stored in, RBAC controls WHICH IDENTITIES
(users, groups, ServiceAccounts) are even PERMITTED to retrieve the
Secret object via the Kubernetes API at all. An identity with no
`get`/`list` permission on Secrets in a given namespace simply cannot
retrieve the Secret through the API, regardless of how easy it would
be to decode its value if they somehow did get hold of it.

How this closes the gap:

Per `k8s1-7`'s own chapter, the real protection measures it named were
"encryption at rest for etcd... RBAC restricting who can read Secret
objects at all... and ideally an external secrets manager." This
chapter delivers on the RBAC piece specifically: by scoping Roles
narrowly (this chapter's own least-privilege material) so that only
the specific ServiceAccounts and users that genuinely need a given
Secret can retrieve it, the number of identities capable of even
ATTEMPTING to decode it drops dramatically -- turning "anyone who can
read the Secret object can trivially decode it" into "only a small,
deliberately chosen set of identities can read the Secret object at
all in the first place." Base64 was never going to solve this on its
own; RBAC is the piece that actually restricts EXPOSURE, which base64
encoding never addressed at all.

WHY THIS WORKS AS AN ANSWER
------------------------------
This distinguishes ENCODING (a format concern, controls nothing about
who can access the data) from ACCESS CONTROL (RBAC, controls exactly
who can retrieve the data regardless of its format) as two entirely
different security dimensions, and shows that RBAC specifically closes
the gap `k8s1-7` identified by restricting EXPOSURE, which was always
the actual missing piece -- not a stronger encoding, but fewer eyes
able to reach the data at all.