こんにちは、SCSKの齋藤です。
Google Cloudでは、このシークレット管理の課題を解決するために「Secret Manager」というサービスを提供しています。Secret Managerは、機密情報を安全に保存、管理、アクセス制御するためのフルマネージドサービスであり、バージョン管理や監査ログ機能も備えています。
本稿では、Cloud RunアプリケーションでSecret Managerを活用する際に検討すべき3つの連携方法を比較し、特に「Cloud Runのボリュームとしてシークレットをマウントする」方法の具体的な設定方法と、そのメリットについて深く掘り下げて解説します。
Cloud RunとSecret Managerの基本
まずはCloud RunとSecret Managerそれぞれの基本的な役割を確認しておきましょう。
Google Cloud Run：サーバーレスコンテナプラットフォーム
Cloud Runは、コンテナイメージからWebサービスやバッチジョブを実行するためのフルマネージドなサーバーレスプラットフォームです。トラフィックに応じて自動的にスケーリングし、リクエストがない場合は0にスケールダウンするため、コスト効率に優れています。開発者はコンテナイメージを用意するだけで、インフラのプロビジョニングや管理を意識することなくアプリケーションを展開できます。
Google Cloud Secret Manager：シークレットの一元管理サービス
Secret Managerは、各種認証情報やAPIキー、証明書といった機密情報を安全に保存・管理するためのサービスです。主な特徴は以下の通りです。
- 集中管理: アプリケーションごとに分散しがちなシークレットを一元的に管理できます。
- バージョン管理: シークレットの変更履歴を自動的に管理し、必要に応じて特定のバージョンにロールバックできます。
- アクセス制御: IAM（Identity and Access Management）と連携し、誰がどのシークレットにアクセスできるかを厳密に制御できます。
- 監査ログ: シークレットへのアクセスや変更履歴を詳細に記録し、コンプライアンス要件への対応を支援します。
- 自動ローテーション（一部対応）: シークレットの自動的な更新をサポートし、セキュリティ強化に貢献します。
Cloud RunでSecret Managerを使用することは、アプリケーションのセキュリティを確保し、運用の手間を削減するための不可欠なステップとなります。
Cloud RunにおけるSecret Managerの連携方法：3つの選択肢
Cloud RunアプリケーションがSecret Managerからシークレット情報を取得する方法は、主に以下の3種類があります。
| Secret Managerを読み込む方法 | 方法 | 特徴（メリット/デメリット） | |
|---|---|---|---|
| 1 | Cloud Runのボリュームとしてマウント | gcloud run jobs create JOB_NAME --image IMAGE_URL --set-secrets=PATH=SECRET_NAME:VERSION |
【メリット】
コンフィグでの依存関係が明確。アプリケーションコードはファイル読み込みのみでポータビリティが高い。環境変数よりもセキュアな提供方法。シークレット変更時の挙動が明確化される。 【デメリット】 インスタンス起動時のシークレットアクセス失敗は実行時エラーとなる。シークレットの自動更新には対応しない場合が多い。 |
| 2 | Cloud Runの環境変数として読み込み | gcloud run jobs update JOB_NAME --set-secrets ENV_VAR_NAME=SECRET_NAME:VERSION |
【メリット】
アプリケーションコードからシンプルに環境変数としてアクセスできる。インスタンス開始前にシークレット取得が行われるため、失敗した場合はインスタンスが起動しない（早期発見）。 【デメリット】 環境変数はプロセスダンプやログから漏洩するリスクがある。コンフィグでの依存関係がやや見えにくい。シークレットが変更されても、インスタンスが再起動されない限りアプリケーションに反映されない。 |
| 3 | プログラムからSecret Manager APIを直接読み込み | SecretManagerServiceClient()を使用 | 【メリット】
Cloud Runというサービスに直接依存しない実装となり、ポータビリティが最も高い。シークレットの動的な取得や、特定のタイミングでの取得が可能。 【デメリット】 アプリケーションコードがSecret Manager APIへの依存性を持つ。権限管理が複雑化する可能性。シークレットへのアクセス回数が増え、運用が複雑になる。どのタイミングでシークレットが参照されるか不透明になる。 |
本稿では、特に「Cloud Runのボリュームとしてシークレットをマウントする」方法に焦点を当て、その具体的な設定とメリットを詳細に解説します。
ボリュームマウントでシークレットをファイルとして利用する方法
Cloud RunでSecret Managerのシークレットをボリュームとしてマウントする方法は、コンテナがファイルシステムからシークレットを読み込めるようにするものです。この方法を設定する具体的なコマンドと、それに伴うメリットを見ていきましょう。
設定方法：–set-secretsオプションの使用
シークレットをボリュームとしてマウントするには、gcloud run jobs create コマンドまたは gcloud run services update コマンド（Cloud Runサービスの場合）で --set-secrets オプションを使用します。
ジョブの場合の例：
gcloud run jobs create MY-BATCH-JOB \
--image gcr.io/my-project/my-batch-app \
--set-secrets=/secrets/db_password=my-database-password:latest \
--region us-central1
このコマンドは、my-database-password というSecret Managerのシークレットの最新バージョンを、コンテナ内の /secrets/db_password というパスにファイルとしてマウントします。アプリケーションは、このパスのファイルを読み込むことでシークレットにアクセスできます。
ボリュームマウント方式のメリット
シークレットをボリュームとしてマウントする方式には、複数のメリットがあります。
-
コンフィグでの依存関係が明確: Cloud Runのデプロイ設定（コマンドラインオプションやYAMLコンフィグレーション）において、どのSecret Managerのシークレットが、どのパスにマウントされるかが明示的に定義されます。これにより、デプロイ設定をレビューするだけで、アプリケーションがどのシークレットに依存しているか、そしてどのバージョンのシークレットを使用しているかが一目で分かり、CI/CDパイプラインの管理やセキュリティ監査の際に可視性が向上します。
-
アプリケーションコードのポータビリティが高い: シークレットをボリュームとしてマウントする方式では、アプリケーションコード自体はファイルシステムからデータを読み込むだけであり、Secret Manager APIへの直接的な依存性を持ちません。これにより、コンテナイメージのポータビリティを高く保つことができます。例えば、開発環境、ステージング環境、本番環境で異なるSecret Managerのシークレットを使用したい場合でも、同じコンテナイメージを使い回し、各環境のデプロイ設定で適切なシークレットをマウントするだけで対応が完結します。
-
よりセキュアな方法でアプリケーションにデータを提供: シークレットをアプリケーションに提供する際、セキュリティは最優先事項です。ボリュームとしてマウントされたシークレットは、コンテナ内のファイルシステムにファイルとして配置されます。これにより、ファイルシステムアクセス権限によって読み取りが制御され、意図しないアクセスを防ぎやすくなります。Kubernetesのセキュリティベストプラクティスにおいても、シークレットを環境変数として直接指定するよりも、ボリュームとしてマウントする方が、プロセスダンプなどからの漏洩リスクが低減されるため、よりセキュアであると推奨されています。
-
シークレット変更時の影響を明確化できる: ボリュームマウント方式の場合、Cloud Runインスタンスの起動時に一度だけシークレットがボリュームに注入されます。これにより、シークレットが変更された際にアプリケーションに新しい値を反映させるには、Cloud Runサービス（またはジョブ）の再デプロイ（または更新）が必要であることが明確になります。この予測可能な挙動は、シークレット変更時の運用計画を立てやすくし、予期せぬ動作を回避する上で有効です。インスタンスの起動時にシークレットへのアクセスが失敗した場合、ボリュームマウントされたシークレットの読み取りも失敗するため、アプリケーションの起動に影響が出ます。これは、シークレットが正しく提供されていないことを早期に検知できるというメリットでもあります。
ローカル開発環境でのシークレット管理
本番環境でSecret Managerをボリュームとしてマウントする方法を用いる一方で、ローカル開発環境でのシークレット管理も考慮する必要があります。開発中にCloud Run環境を完全に再現し、シークレットをマウントすることは非効率的です。
ローカルでの実行時には、以下の手順でシークレットを管理する方法も検討することをお勧めします。
- Secret Managerからのシークレット取得:
gcloud secrets versions access latest --secret=SECRET_NAMEコマンドを使用して、Secret Managerから対象のシークレットの最新バージョンを一時的に取得します。必要に応じて特定のバージョンを指定することも可能です。 - 環境変数への設定: 取得したシークレットの値を、ローカル環境の環境変数として設定します。例えば、Bashでは
export MY_API_KEY="取得したシークレットの値"のように設定します。 - アプリケーションの実行: 設定した環境変数を使用して、アプリケーションをローカルで実行します。
このアプローチにより、本番環境ではファイルシステムからシークレットを読み込むアプリケーションが、ローカルでは環境変数からシークレットを読み込む形となり、開発と本番の間のシークレット取得方法の差異を吸収しつつ、安全な開発環境を維持できます。アプリケーションコードは、単に「MY_API_KEYという値（ファイルまたは環境変数）を読み込む」という抽象化されたロジックに留めることが可能です。
まとめ
クラウドネイティブな環境におけるシークレット管理は、アプリケーションのセキュリティと運用効率の根幹をなす要素です。Google Cloud Secret Managerは、その強力な機能によってこの課題を解決する重要なサービスであり、Cloud Runとの連携はサーバーレスアプリケーションの安全な運用に不可欠です。
本稿で解説したように、Cloud RunでSecret Managerを活用する方法は複数存在します。その中でも、「Cloud Runのボリュームとしてシークレットをマウントする」方法は、以下の点で注目すべき特徴とメリットを提供します。
- 設定の可視性が高く、運用管理が容易である点。
- アプリケーションコードのポータビリティを維持し、環境間で同じコンテナイメージを再利用しやすい点。
- 環境変数に比べてシークレットの露出リスクが低く、Kubernetesのセキュリティベストプラクティスにも合致する、よりセキュアな提供方法である点。
- シークレット変更時のアプリケーションの挙動が予測しやすく、運用計画やトラブルシューティングが容易である点。
どの方法を選択するかは、アプリケーションの特性、チームのスキルセット、組織のセキュリティポリシーによって最適な判断が異なります。しかし、上記で述べたボリュームマウント方式のメリットは、Cloud Runでのシークレット管理戦略を検討する上で重要な考慮点となるでしょう。
安全で効率的なクラウドネイティブ開発を目指す上で、Google Cloud RunとSecret Managerを組み合わせたセキュアなシークレット管理は不可欠な要素です。本稿が、貴社のクラウド環境におけるシークレット管理戦略の策定に役立ち、より堅牢なシステム構築の一助となれば幸いです。
参考資料
- Cloud Run にシークレットを構成する – Google Cloud 公式ドキュメント
- Secret Manager の概要 – Google Cloud 公式ドキュメント