Wie verwalten Sie zentralisierte Konfiguration und Secrets in mehreren Services?

Question

Accepted Answer

Mit Dutzenden von Services können Sie Konfiguration und Secrets nicht ad hoc pro Deployment verwalten. **Zentralisierte Konfiguration** hält Einstellungen in einer verwalteten Quelle, und **Secrets Manager** speichern sensible Werte sicher.

## Externalisierte Konfiguration

Konfiguration lebt außerhalb des Build-Artefakts, sodass dasselbe Image in dev/staging/prod mit verschiedenen Einstellungen läuft.

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

## Konfigurationsansätze

| Ansatz | Beispiel |
|---|---|
| Config-Server | Spring Cloud Config, Consul |
| Orchestrator-nativ | Kubernetes ConfigMaps |
| Secrets Manager | HashiCorp Vault, AWS Secrets Manager |

## Secrets — halten Sie sie separat

Speichern Sie Secrets niemals in Plain ConfigMaps oder Git.

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

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

## Warum es wichtig ist

Zentralisierte Konfiguration ermöglicht es Ihnen, das Verhalten (Timeouts, Feature Flags) zu ändern und Anmeldedaten über viele Services hinweg zu rotieren, ohne jeden einzelnen zu rekompilieren und neu bereitzustellen.

Secrets in einem echten Secrets Manager zu speichern – nicht in Images oder Git – ist eine grundlegende Sicherheitsanforderung, die mit der Anzahl der Services skaliert.

Ansatz	Beispiel
Config-Server	Spring Cloud Config, Consul
Orchestrator-nativ	Kubernetes ConfigMaps
Secrets Manager	HashiCorp Vault, AWS Secrets Manager