Cum gestionezi configurația centralizată și secretele în mai multe servicii?

Question

Accepted Answer

Cu zeci de servicii, nu poți gestiona configurația și secretele ad hoc pentru fiecare implementare. **Configurația centralizată** păstrează setările într-o sursă unică gestionată, iar **managerele de secrete** stochează valorile sensibile în siguranță.

## Configurație externalizată

Configuația se află în afara artefactului de build, deci aceeași imagine rulează în dev/staging/prod cu setări diferite.

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

## Abordări de configurație

| Abordare | Exemplu |
|---|---|
| Server de configurație | Spring Cloud Config, Consul |
| Nativ pentru orchestrator | Kubernetes ConfigMaps |
| Manager de secrete | HashiCorp Vault, AWS Secrets Manager |

## Secrete — ține-le separate

Nu stoca niciodată secrete în ConfigMaps simple sau git.

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

## Bune practici

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

## De ce este important

Configuația centralizată te permite să schimbi comportamentul (timeouts, feature flags) și să rotezi acreditările în mai multe servicii fără a reconstrui și redeploya fiecare dintre ele.

Păstrarea secretelor într-un manager de secrete real — nu în imagini sau git — este o cerință de securitate de bază care se scalează cu numărul de servicii.

Abordare	Exemplu
Server de configurație	Spring Cloud Config, Consul
Nativ pentru orchestrator	Kubernetes ConfigMaps
Manager de secrete	HashiCorp Vault, AWS Secrets Manager