Con dozzine di servizi, non puoi gestire configurazioni e segreti in modo ad hoc per ogni deployment. La configurazione centralizzata mantiene le impostazioni in un'unica fonte gestita, e i gestori di segreti archiviano i valori sensibili in modo sicuro.
La configurazione si trova al di fuori dell'artefatto build, quindi la stessa immagine viene eseguita in dev/staging/prod con impostazioni diverse.
| Approccio | Esempio |
|---|---|
| Config server | Spring Cloud Config, Consul |
| Nativo dell'orchestrator | Kubernetes ConfigMaps |
| Secrets manager | HashiCorp Vault, AWS Secrets Manager |
Non archiviare mai segreti in ConfigMaps in chiaro o in git.
# fetch a secret at startup, short-lived, audited
export DB_PASSWORD=$(vault kv get -field=password secret/orders/db)
✓ 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
La configurazione centralizzata ti consente di modificare il comportamento (timeout, feature flag) e ruotare le credenziali su molti servizi senza ricostruire e ridistribuire ognuno.
Mantenere i segreti in un vero gestore di segreti — non in immagini o git — è un requisito di sicurezza di base che si adatta al numero di servizi.