Configuration & Secrets

## What "externalized configuration" means **Externalized configuration** means any value that changes between deploys or environments without changing the application's behavior in code — connection strings, credentials, thread-pool sizes, timeouts, feature flags, log levels — lives outside the compiled artifact and is injected at runtime. The **12-factor app** methodology's "Config" factor says: build one immutable artifact (a jar, a container image) and supply config at runtime via - environment variables, - mounted config files/ConfigMaps, - or a dedicated config service the app queries at startup. Concretely, a Spring Boot service reads defaults from `application.yml`, and Spring's property resolution order lets environment variables (like `DATABASE_URL`), JVM system properties, or a Config Server override those defaults per profile (`dev`, `staging`, `prod`) — so a Kubernetes ConfigMap or Secret mounted as env vars determines behavior without touching the built jar. ## Why it exists This exists because microservices multiply the number of places configuration lives. If values are hardcoded or baked in at build time, every environment needs its own build, which breaks the promise of "build once, promote the same artifact through the pipeline" and increases the risk that what you tested isn't actually what you ship. Externalizing config also separates **who can change config** (ops, SRE, feature owners) from **who can change code** (gated by code review and CI), enabling faster, lower-risk operational changes — like rotating a credential or tuning a timeout under load — without a full build-and-deploy cycle for every tweak. ## The trade-off, in both directions The trade-off runs both directions. Externalizing adds **indirection**. You now need a place to store, version, and secure config: - env vars in orchestrator specs, - a git-backed config repo, - a config server. And if that store is inconsistent across environments you get "works on my machine" bugs at the config layer instead of the code layer. **Over-externalizing** — turning every constant into a flag — creates config sprawl that's hard to audit, so mature setups add a config schema or validation step to keep it sane. And treating secrets as just another config value is itself a risky trade-off: **secrets need extra protection** (encryption, access auditing, rotation) that ordinary config doesn't, so lumping them into the same plaintext pipeline is a common anti-pattern. ## Failure modes in production In production, several failure modes recur. 1. **A missing or misspelled environment variable** can silently fall back to a default that's wrong for production (say, pointing at an in-memory test database) rather than causing a hard, obvious failure — this is why fail-fast validation at startup matters. 2. **Environment drift** is another: staging's ConfigMap slowly diverges from production's over months of ad hoc tweaks, until a staging-only bug appears in prod, or vice versa. 3. **Type mismatches** — a config value parsed as the string "true" in one environment's loader but expected as a boolean in another — can pass validation in one place and silently misbehave in another. 4. **Config dumped at startup** for debugging purposes can accidentally leak secrets into logs if secrets weren't segregated from ordinary config in the first place. ## Where it shows up A concrete real-world pattern: Kubernetes ConfigMaps and Secrets mounted as environment variables or volumes are now the standard runtime mechanism for this, often paired with a centralized store like **Spring Cloud Config** or **HashiCorp Consul** for per-service, per-environment key-value configuration that's centrally managed, versioned, and audited. This lets a platform team change a shared timeout value for many services in staging with a single commit, and roll it forward to production through the normal promotion pipeline, with zero code changes and zero rebuilds — exactly the operational agility that hardcoded configuration would make impossible.