複数のサービス間で集中管理された設定とシークレットをどのように処理しますか?

Question

IT Interview Practice · Accepted Answer

数十のサービスがある場合、デプロイメントごとに設定とシークレットをアドホックに管理することはできません。集中管理された設定は設定を1つの管理されたソースに保ち、シークレットマネージャーは機密値を安全に保存します。

外部化された設定

設定はビルドアーティファクトの外に存在するため、同じイメージがdev/staging/prodで異なる設定で実行されます。

yaml

## 外部化された設定

設定はビルドアーティファクトの外に存在するため、同じイメージがdev/staging/prodで異なる設定で実行されます。

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

## 設定のアプローチ

| アプローチ | 例 |
|---|---|
| Config server | Spring Cloud Config、Consul |
| オーケストレーター固有 | Kubernetes ConfigMaps |
| Secrets manager | HashiCorp Vault、AWS Secrets Manager |

## シークレット — 分離したままにしておく

プレーンなConfigMapsやgitにシークレットを保存しないでください。

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

## ベストプラクティス

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

## なぜ重要なのか

集中管理された設定により、多くのサービス全体で動作(タイムアウト、フィーチャーフラグ)を変更し、各サービスを再構築および再デプロイすることなく認証情報をローテーションできます。

シークレットを実際のシークレットマネージャーに保持する — イメージやgitではなく — はサービスの数に応じてスケールする基本的なセキュリティ要件です。

アプローチ	例
Config server	Spring Cloud Config、Consul
オーケストレーター固有	Kubernetes ConfigMaps
Secrets manager	HashiCorp Vault、AWS Secrets Manager

外部化された設定

設定のアプローチ

シークレット — 分離したままにしておく

ベストプラクティス

なぜ重要なのか

関連する質問