Hvordan håndterer du centraliseret konfiguration og hemmeligheder på tværs af tjenester?

Question

Accepted Answer

Med dusinvis af tjenester kan du ikke håndtere config og hemmeligheder ad hoc pr. deployment. **Centraliseret konfiguration** holder indstillinger i én administreret kilde, og **hemmeligheds-managers** lagrer følsomme værdier sikkert.

## Eksternt konfigureret

Konfiguration ligger uden for build-artefakten, så samme image køres i dev/staging/prod med forskellige indstillinger.

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

## Konfigurationstilgange

| Tilgang | Eksempel |
|---|---|
| Config-server | Spring Cloud Config, Consul |
| Orchestrator-nativ | Kubernetes ConfigMaps |
| Hemmeligheds-manager | HashiCorp Vault, AWS Secrets Manager |

## Hemmeligheder — hold dem adskilt

Gem aldrig hemmeligheder i almindelige ConfigMaps eller git.

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

## God praksis

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

## Hvorfor det betyder noget

Centraliseret konfiguration lader dig ændre adfærd (timeouts, feature flags) og rotere legitimationsoplysninger på tværs af mange tjenester uden at genopbygge og genudrulle hver enkelt.

At holde hemmeligheder i en rigtig hemmeligheds-manager — ikke i images eller git — er et grundlæggende sikkerhedskrav, der skaleres med antallet af tjenester.

Tilgang	Eksempel
Config-server	Spring Cloud Config, Consul
Orchestrator-nativ	Kubernetes ConfigMaps
Hemmeligheds-manager	HashiCorp Vault, AWS Secrets Manager