このガイドでは、Secret Manager を使用する際のベスト プラクティスについて説明します。このガイドは、すべての推奨事項を説明するものではありません。このガイドを読む前に、プラットフォームの概要を確認して、Google Cloud の全体像と Secret Manager の概要を理解することをおすすめします。
アクセス制御
Secret Manager API へのアクセスは IAM によって保護されています。 シークレットに権限を付与する際は、最小権限の原則に従います。
- 組織の所有権を保護された特権管理者アカウントに制限します。
- Google Cloud ランディング ゾーンのリソース階層を決定するで説明されているように、アプリケーションと環境（ステージング/本番環境）を別々のプロジェクトにセグメント化します。これにより、プロジェクト レベルの IAM バインディングで環境を分離することに役立たせることができ、割り当てを個別に適用することを保証します。
- 必要な最小限の権限を持つキュレートされたロールを選択するか、必要に応じてカスタムロールを作成します。
- 多数のサービスのシークレットを 1 つのプロジェクトに含める場合は、シークレット レベルの IAM バインディング、または IAM Conditions を使用して、必要なシークレットのサブセットへのアクセスを制限します。
- IAM Recommender を使用すると、特権 IAM バインディングの識別にさらに役立ちます。
Secret Manager API への認証には、認証情報が必要です。クライアント ライブラリはすべて似たような手段を使用して「アプリケーションのデフォルト認証情報」と呼ばれる認証情報を検索します。
- ローカルで開発する場合は、
gcloud auth application-default loginを使用します。これにより、クライアント ライブラリによって自動的に取得される認証情報を含むファイルが作成されます。 - Compute Engine や Cloud Run 関数など、他の Google Cloud コンピューティング プラットフォームでは、クライアント ライブラリはインスタンス メタデータ サーバーを介して認証情報を取得します。
- GKE では、Workload Identity はメタデータ サービスを介して認証情報も提供します。
- Amazon Web Services や Microsoft Azure など、他のプラットフォームでは、既存の ID メカニズムを使用して Google Cloud APIs に対する認証を行う Workload Identity 連携を設定することを検討してください。
Secret Manager API の外部に追加のシークレットを安全に保存し、アクセスする必要がないため、これらの方法はすべて、サービス アカウントの認証情報をエクスポートする方法よりも好ましい方法です。
コーディング手法
ファイル システムまたは環境変数を介してアプリケーションにシークレットを渡すのは一般的ですが、次の理由から、可能な限り避けてください。
- ファイル システムでシークレットにアクセスできると、攻撃者がシークレット マテリアルを読み取ることができるため、ディレクトリ トラバーサル攻撃などのアプリケーションの脆弱性が深刻化する可能性があります。
- 環境変数を介してシークレットが使用されると、デバッグ エンドポイントの有効化やプロセス環境の詳細をログに記録する依存関係などの構成ミスにより、シークレットが漏洩する可能性があります。
- シークレット マテリアルを別のデータストア（Kubernetes Secret など）に同期する場合は、そのデータストアのアクセス制御を検討してください。次に例を示します。
- データストアによりシークレットへのアクセスは拡張されていますか？
- シークレットへのアクセスを監査できますか？
- データストアは、保存データの暗号化とリージョン指定の要件に準拠していますか？
Secret Manager API は、提供されているいずれかのクライアント ライブラリを直接使用するか、REST または GRPC のドキュメントに従うことをおすすめします。
ただし、サーバーレス統合などの一部のプロダクト統合では、ファイル システムまたは環境変数を介して Secret を渡す場合があります。詳細については、他のプロダクトで Secret Manager を使用するをご覧ください。
管理
ワークロードに特定のロケーション要件（constraints/gcp.resourceLocations 制約を使用して適用可能）がない限り、シークレットを作成する際に、自動レプリケーション ポリシーを選択します。
シークレットを最新のエイリアスを使用するのではなくバージョン番号で参照する。既存のリリース プロセスを使用して、バージョン番号に更新をデプロイします。通常、これは、起動時に読み込まれる特定のシークレット バージョンを使用してアプリケーションを構成することを意味します。最新のエイリアスを使用すると便利な場合がありますが、シークレットの新しいバージョンに問題がある場合は、ワークロードでシークレット バージョンを使用できない可能性があります。バージョン番号に固定すると、既存のリリース プロセスを使用して、構成の検証とロールバックを行うことができます。
シークレット バージョンを破棄する前、またはシークレットを削除する前に、シークレット バージョンを無効にします。これによって、シークレットを破棄したように見えますが、元に戻せる状態にすることで、停止を防ぐことができます。つまり、データを完全に削除する前に、依存関係が残らないようにするために、無効にして 1 週間待機します。
本番環境のシークレットに有効期限を設定しないでください。これは、シークレットを完全に削除する必要がある場合にのみ行ってください。有効期限機能は、一時的な環境の自動クリーンアップに最適です。有効期限付きのシークレットの代わりに、時間ベースの IAM 条件を検討してください。
以下の目的のために、定期的にシークレットをローテーションします。
- シークレットの漏洩が発生した場合の影響を制限する。
- シークレットへのアクセスが不要になった個人に対して、以前にアクセスしたシークレットの使用を継続できないようにする。
- ローテーション フローを継続的に実施して、停止の可能性を減らす。
以下の目的のために、Cloud Asset Inventory を使用して組織全体のシークレットをモニタリングします。
- 組織全体のシークレットの識別に役立てる。
- ローテーション、暗号化構成、ロケーションなどの組織要件に対する不遵守を特定する。
データアクセス ログを有効にして、AccessSecretVersion リクエスト情報を取得、分析します。フォルダレベルまたは組織レベルでこれを有効にすると、すべてのシークレットやプロジェクトで構成しなくてもロギングを適用できます。
IAM による制御に加えて、ネットワーク ベースの制御で Secret Manager API へのアクセスを制限するには、組織に VPC Service Controls の境界を設定します。
constraints/iam.allowedPolicyMemberDomains 組織のポリシーを使用すると、シークレットの IAM ポリシーに追加できる ID を制限するのに使用できます。
ピーク時のシークレット使用量（アプリケーションの同時デプロイやサービスの自動スケーリングによる「thundering herd」を考慮）を推定し、そのようなイベントに対処できるように、プロジェクトに十分な割り当てを行ってください。さらに割り当てが必要な場合は、割り当ての引き上げをリクエストします。