Configuration and secret boundaries

Trace a value from author to process

Configuration tells an application how to behave: a database hostname, a logging level or a queue name. A secret is a value whose disclosure grants access or exposes confidential information. Both may reach a process through environment variables or mounted files, but they require different storage and access decisions.

A Kubernetes Secret reference is an address for a value, not a secret-distribution system. Someone must create the named object, rotate the value when needed and check how the application reloads it. Base64 representation is not encryption.

Configuration has different lifetimes

MicroBank's earlier labs keep private runtime values outside Git and reference a Kubernetes Secret. That separates configuration from secrets, but a complete secret-management service needs more. The owner must also decide how credentials are created, distributed, rotated, revoked, and recovered.

Database endpoints and queue names may differ by environment. Credentials differ by identity and target. Build-time frontend variables are included in browser-delivered assets, so a Vite variable is not a safe place for a private API key. The frontend's Auth0 integration also does not establish backend authorization.

Evaluate a secret delivery mechanism

External Secrets, a secrets-store CSI driver, or encrypted Git material can each fit a design. Compare where plaintext exists, who can decrypt/read it, what happens when the external store is unavailable, and how applications reload rotated values. Installing an operator without those decisions does not complete the workflow.

For the first local platform lab, keep the existing microbank-runtime Secret under its existing owner. Do not let the workload Application prune it. Document the required keys and consumer services without copying the values into the catalog.

Classify these MicroBank settings

Now follow a password rotation on paper. The secret store receives a replacement value. Its delivery mechanism updates the Kubernetes Secret. A Pod that read the old value from its environment does not magically change its running process environment. You need the application's documented reload or restart procedure and a compatible database credential transition. Test the connection after rotation; seeing a changed Secret object proves only the delivery step.

For this path, inspect envFrom.secretRef, individual env[].valueFrom.secretKeyRef entries, and Secret-backed volumes where present. The inherited MicroBank profile imports microbank-runtime through envFrom.secretRef: that names the Secret but does not list its keys in the Deployment. Read the required keys from the documented runtime configuration, then compare them with the owner's provisioning process. Inspect names and metadata without printing secret values into a terminal recording or public notes.

Try it

Inspect configuration references in the chosen base and produce a table: key, consumer, source, owner, rotation behavior. Inspect names and references rather than printing Secret contents. Keep .local/, .study.env, state, saved plans, and raw case evidence excluded from Git and container build contexts.

Select one dependency to rotate in a later disposable exercise. Plan how to verify the old credential stops working and the same application flow recovers. Carry out the rotation only when the verification and recovery steps are ready.

Checkpoint and revision

Explain why base64 is not encryption, why Secret access needs RBAC, and why a successful deployment cannot prove rotation works. Environment names provide organization; identity and access controls provide separation.

Compare your reasoning

A rendered manifest that references microbank-runtime can be valid while the Secret is absent. That failure belongs to the target's dependency setup. The portal must not display Secret contents to help the user diagnose a missing key.

Sources

Kubernetes Secrets↗.

Kubernetes Secret practices↗, External Secrets↗, Vite environment exposure↗.