Configuration Management and Secrets

Configuration management encompasses two distinct problems: managing application configuration (non-sensitive settings) and managing secrets (credentials, keys, certificates). Both are critical to a secure, reproducible deployment pipeline.

The 12-Factor App: Config

The 12-Factor App methodology defines a best-practice approach to building cloud-native applications. Factor III — Config — states that everything that varies between deployments (staging, production, developer workstations) should be stored in environment variables, not in the application code.

Config includes:

• Database URLs and connection strings
• External service endpoints (payment processors, email APIs)
• Feature flags and environment names
• Resource handles and credentials

A strict test: could you open-source your codebase right now without exposing credentials? If no, config has leaked into code.

Environment Variables and .env Files

Environment variables are the standard mechanism for passing config to a process. In development, .env files (loaded by tools like dotenv) provide a convenient way to set them locally. Critical rules:

• Always add .env to .gitignore — never commit real secrets
• Provide a .env.example with placeholder values so new developers know what to configure
• In CI/CD, inject secrets via the platform secret store (GitHub Actions secrets, GitLab CI variables) — they are masked in logs

Secrets Managers

For production systems, environment variables stored in CI/CD are insufficient. Secrets managers provide centralised, auditable, rotatable secret storage:

Dynamic Secrets with HashiCorp Vault

One of Vault's most powerful features is dynamic secrets: instead of storing a long-lived database password, Vault generates a unique, time-limited credential on demand. The credential expires automatically — there is no static password to leak or rotate.

Example flow for a Kubernetes pod needing database access:

1. Pod authenticates to Vault using its Kubernetes service account JWT
2. Vault verifies the service account and grants a lease
3. Vault generates a unique PostgreSQL username and password with the required permissions
4. The application uses the credential; it expires after the lease TTL (e.g., 1 hour)

External Secrets Operator (ESO)

In Kubernetes environments, the External Secrets Operator bridges secrets managers and Kubernetes Secrets. You define an ExternalSecret resource that references a secret in AWS Secrets Manager, GCP Secret Manager, or Vault. ESO fetches the value and creates/updates a Kubernetes Secret. Applications consume the Kubernetes Secret as normal — they need no knowledge of the underlying secrets manager.

Configuration Management Tools

For managing configuration across fleets of servers (particularly in VM-based or hybrid environments), configuration management tools enforce a desired state:

In container-based environments, configuration management tools are less central — the immutable container image replaces the configured server. However, Ansible remains widely used for bootstrapping VMs, configuring bare-metal hosts, and running operational tasks across fleets.