Hvordan håndterer du sentralisert konfigurasjon og hemmeligheter på tvers av tjenester?

Question

Accepted Answer

Med dusinvis av tjenester kan du ikke håndtere konfigurasjon og hemmeligheter ad hoc per implementering. **Sentralisert konfigurasjon** holder innstillinger i én administrert kilde, og **secrets managers** lagrer følsomme verdier på en sikker måte.

## Eksternalisert konfigurasjon

Konfigurasjon lever utenfor byggeartefakten, så det samme bildet kjører i dev/staging/prod med ulike innstillinger.

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

## Konfigurasjonsmåter

| Måte | Eksempel |
|---|---|
| Konfigurasjonsserver | Spring Cloud Config, Consul |
| Orkestrator-innebygd | Kubernetes ConfigMaps |
| Secrets manager | HashiCorp Vault, AWS Secrets Manager |

## Hemmeligheter — keep them separate

Stall aldri hemmeligheter i vanlige 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 betyr noe

Sentralisert konfigurasjon lar deg endre atferd (timeouts, feature flags) og rotere legitimasjon på tvers av mange tjenester uten å bygge og implementere hver enkelt på nytt.

Å holde hemmeligheter i en ekte secrets manager — ikke i bilder eller git — er et grunnleggende sikkerhetskrav som skaleres med antallet tjenester.

Måte	Eksempel
Konfigurasjonsserver	Spring Cloud Config, Consul
Orkestrator-innebygd	Kubernetes ConfigMaps
Secrets manager	HashiCorp Vault, AWS Secrets Manager