Com dezenas de serviços, você não pode gerenciar configuração e segredos ad hoc por implantação. Configuração centralizada mantém as configurações em uma única fonte gerenciada, e gerenciadores de segredos armazenam valores sensíveis com segurança.
A configuração fica fora do artefato de build, então a mesma imagem é executada em dev/staging/prod com configurações diferentes.
| Abordagem | Exemplo |
|---|---|
| Servidor de configuração | Spring Cloud Config, Consul |
| Nativa do orquestrador | Kubernetes ConfigMaps |
| Gerenciador de segredos | HashiCorp Vault, AWS Secrets Manager |
Nunca armazene segredos em ConfigMaps simples ou 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
A configuração centralizada permite alterar o comportamento (timeouts, feature flags) e girar credenciais em vários serviços sem reconstruir e reimplementar cada um.
Manter segredos em um gerenciador de segredos real — não em imagens ou git — é um requisito de segurança básico que se dimensiona com o número de serviços.