このガイドでは、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 Functions など、他の 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 Manager を使用するをご覧ください。
アドミニストレーション
ワークロードに特定のロケーション要件（constraints/gcp.resourceLocations 制約を使用して適用可能）がない限り、シークレットを作成する際に、自動レプリケーション ポリシーを選択します。
シークレットを最新のエイリアスを使用するのではなくバージョン番号で参照する。既存のリリース プロセスを使用して、バージョン番号に更新をデプロイします。通常は、起動時に読み込まれる特定のシークレット バージョンを使用してアプリケーションを構成します。最新のエイリアスを使用するのが便利ですが、シークレットの新しいバージョンに問題がある場合は、ワークロードでシークレット バージョンを使用できない可能性があります。バージョン番号に固定すると、既存のリリース プロセスを使用して、構成の検証とロールバックを行うことができます。
シークレット バージョンを破棄する前、またはシークレットを削除する前に、シークレット バージョンを無効にします。これによって、シークレットを破棄したように見えますが、元に戻せる状態にすることで、停止を防ぐことができます。つまり、データを完全に削除する前に、依存関係が残らないようにするために、無効にして 1 週間待機します。
不可逆で削除する必要がある場合を除き、本番環境のシークレットには有効期限を設定しないでください。有効期限の機能は、一時的な環境の自動クリーンアップに最適です。シークレットを期限切れにする代わりに、時間ベースの IAM 条件を検討してください。
定期的にシークレットをローテーションして、次のことを行います。
- シークレットの漏洩が発生した場合の影響を制限する。
- シークレットへのアクセスが不要になった個人に対して、以前にアクセスしたシークレットの使用を継続できないようにする。
- ローテーション フローを継続的に実施して、停止の可能性を減らす。
以下の目的のために、Cloud Asset Inventory を使用して組織全体のシークレットをモニタリングします。
- 組織全体のシークレットの識別に役立てる。
- ローテーション、暗号化構成、ロケーションなどの組織要件に対する不遵守を特定する。
データアクセス ログを有効にして、AccessSecretVersion リクエスト情報を取得、分析します。フォルダレベルまたは組織レベルでこれを有効にすると、すべてのシークレットやプロジェクトで構成しなくてもロギングを適用できます。
IAM による制御に加えて、ネットワーク ベースの制御で Secret Manager API へのアクセスを制限するには、組織に VPC Service Controls の境界を設定します。
constraints/iam.allowedPolicyMemberDomains 組織のポリシーを使用すると、シークレットの IAM ポリシーに追加できる ID を制限するのに使用できます。
ピーク時のシークレット使用量（アプリケーションの同時デプロイやサービスの自動スケーリングによる「thundering herd」を考慮）を推定し、そのようなイベントに対処できるように、プロジェクトに十分な割り当てを行ってください。さらに割り当てが必要な場合は、割り当ての引き上げをリクエストします。