数十のサービスがある場合、デプロイメントごとに設定とシークレットをアドホックに管理することはできません。集中管理された設定は設定を1つの管理されたソースに保ち、シークレットマネージャーは機密値を安全に保存します。
設定はビルドアーティファクトの外に存在するため、同じイメージがdev/staging/prodで異なる設定で実行されます。
# values injected at runtime, not baked into the image
DATABASE_URL: ${DB_URL} # per-environment
FEATURE_NEW_CHECKOUT: "true" # toggle without redeploy
| アプローチ | 例 |
|---|---|
| Config server | Spring Cloud Config、Consul |
| オーケストレーター固有 | Kubernetes ConfigMaps |
| Secrets manager | HashiCorp Vault、AWS Secrets Manager |
プレーンなConfigMapsや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
集中管理された設定により、多くのサービス全体で動作(タイムアウト、フィーチャーフラグ)を変更し、各サービスを再構築および再デプロイすることなく認証情報をローテーションできます。
シークレットを実際のシークレットマネージャーに保持する — イメージやgitではなく — はサービスの数に応じてスケールする基本的なセキュリティ要件です。