Hoe ga je om met gecentraliseerde configuratie en geheimen voor services?

Question

Accepted Answer

Met tientallen services kun je configuratie en geheimen niet ad hoc per implementatie beheren. **Gecentraliseerde configuratie** houdt instellingen in één beheerde bron, en **secrets managers** slaan gevoelige waarden veilig op.

## Geëxternaliseerde configuratie

Configuratiegegevens bevinden zich buiten het build-artefact, zodat dezelfde image in dev/staging/prod wordt uitgevoerd met verschillende instellingen.

```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"
```

## Configuratie-benaderingen

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

## Geheimen — houd ze apart

Sla nooit geheimen in gewone ConfigMaps of git op.

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

## Goede praktijken

```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
```

## Waarom het belangrijk is

Gecentraliseerde configuratie laat je gedrag (timeouts, feature flags) wijzigen en credentials roteren over veel services zonder elk ervan opnieuw op te bouwen en opnieuw in te zetten.

Geheimen in een echte secrets manager houden — niet in images of git — is een basisvereiste voor beveiliging die schaalt met het aantal services.

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