How do you handle centralized configuration and secrets across services?

Question

Accepted Answer

With dozens of services, you can't manage config and secrets ad hoc per deployment. **Centralized configuration** keeps settings in one managed source, and **secrets managers** store sensitive values securely.

## Externalized config

Config lives outside the build artifact, so the same image runs in dev/staging/prod with different settings.

```yaml
# values injected at runtime, not baked into the image
DATABASE_URL: ${DB_URL}        # per-environment
FEATURE_NEW_CHECKOUT: "true"   # toggle without redeploy
PAYMENT_TIMEOUT_MS: "3000"
```

## Config approaches

| Approach | Example |
|---|---|
| Config server | Spring Cloud Config, Consul |
| Orchestrator-native | Kubernetes ConfigMaps |
| Secrets manager | HashiCorp Vault, AWS Secrets Manager |

## Secrets — keep them separate

Never store secrets in plain ConfigMaps or git.

```bash
# fetch a secret at startup, short-lived, audited
export DB_PASSWORD=$(vault kv get -field=password secret/orders/db)
```

## Good practices

```text
✓ Externalize config (12-factor): config in the environment
✓ Secrets in a dedicated manager with rotation + audit logs
✓ Dynamic refresh for non-secret toggles (no redeploy)
✗ Never commit secrets to source control
```

## Why it matters

Centralized config lets you change behavior (timeouts, feature flags) and rotate credentials across many services without rebuilding and redeploying each one.

Keeping secrets in a real secrets manager — not in images or git — is a baseline security requirement that scales with the number of services.

Approach	Example
Config server	Spring Cloud Config, Consul
Orchestrator-native	Kubernetes ConfigMaps
Secrets manager	HashiCorp Vault, AWS Secrets Manager