Exercise 1: Why base64 Isn't Real Security, and What Would Be — Possible Solution
====================================================================

Why base64 encoding alone provides no real security:

Base64 is an ENCODING scheme, not an ENCRYPTION scheme -- it has no
secret key involved at all, and its entire purpose is to represent
binary or text data in a different, transportable text format, not to
hide it from anyone. Per the chapter, "anyone with read access to the
Secret object -- or to etcd directly... can trivially decode it back
to plaintext." Decoding base64 requires no password, no key, and no
special tool -- it's a simple, publicly known, reversible
transformation that any standard library or even a basic command-line
utility can undo instantly. Storing a password as base64 is
functionally equivalent to storing it in plaintext for anyone who
already has read access to the Secret object or the underlying etcd
data -- it adds no meaningful barrier at all.

Two additional measures that would provide genuine protection:

1. ENCRYPTION AT REST FOR ETCD. Since etcd holds the Secret's
   base64-encoded value, encrypting etcd's own stored data means that
   even someone who somehow obtained raw access to etcd's underlying
   storage would find genuinely encrypted data, not just
   base64-encoded (trivially reversible) data -- this is the `crypto1-
   5/6`/`dbsec1-5`-style encryption-at-rest protection applied
   specifically to the cluster's own state store.

2. RBAC RESTRICTING WHO CAN READ SECRET OBJECTS. Per the chapter,
   limiting which identities are even PERMITTED to read Secret objects
   in the first place (Course 2's `k8s2-4` covers this in depth)
   ensures that even though the Secret's value is only base64-encoded
   underneath, far fewer people/processes have the ACCESS needed to
   retrieve and decode it in the first place -- reducing exposure even
   without changing the underlying encoding itself.

(A third valid measure, also named in the chapter: using an external
secrets manager, tying to `cloud1-11`'s own KMS material, for
genuinely sensitive production secrets rather than relying on raw
Kubernetes Secrets alone.)

WHY THIS WORKS AS AN ANSWER
------------------------------
This distinguishes ENCODING (base64, reversible by anyone, no key
required) from ENCRYPTION (requires a key, genuinely hides the data)
as the core reason the chapter's warning holds, and then names two of
the chapter's own explicitly stated additional measures rather than
inventing unrelated ones.