PCD#352(integrating)
GKE 上のワークロードから Cloud SQL に接続する際、シークレット管理を簡素化しつつ短命な IAM トークンで認証する方式を検討しています。データベース側に静的パスワードを保持したくありません。どの方法が要件に合致しますか？
正解：B
正解の根拠
Cloud SQL の IAM Database Authentication は、PostgreSQL と MySQL の DB ユーザーを IAM プリンシパルに紐付け、短命なアクセストークンをパスワードとして利用する仕組みです。Workload Identity と組み合わせることで、Pod が静的鍵を持たずに認証できます。
方式比較
| 方式 | クレデンシャル | ローテーション | 監査 |
|---|---|---|---|
| IAM DB Auth | 短命 OAuth トークン | 自動 (1 時間) | IAM 監査ログ統合 |
| Secret Manager + 静的 PW | 静的パスワード | 手動運用 | 取得操作のみ監査 |
有効化手順
- Cloud SQL のフラグ
cloudsql.iam_authenticationを on にします - IAM プリンシパルに
cloudsql.instanceUser権限を付与します - DB 側で
CREATE USER "sa@project.iam" WITH LOGINを実行します - クライアントは
gcloud sql generate-login-token相当のトークンをパスワードとして使用します
不正解の理由
- A: Secret Manager は便利ですが、静的パスワードのままでは漏えい時の影響範囲が広く、短命トークンを要件とする本問の最適解にはなりません。
- C: Service Account 鍵 JSON のマウントは長期鍵運用となり、Workload Identity の利点を放棄する設計です。
- D: ConfigMap の暗号化配布は仕組みが複雑な割に静的パスワードへの依存が残り、要件を満たしません。
コメント