SECRET
MANAGER
秘密を、
安全に渡す仕組み
Secret Managerは、APIキーやパスワードを保管する「金庫」だけではありません。 誰が、どの秘密を、いつ取得できるかを、ID・権限・履歴と一緒に管理する仕組みです。
身元と権限を確認してから秘密を返し、その操作を監査ログへ残します。
CONTENTSこの記事の目次＋
01 — THE PROBLEM
秘密をコードに
置けない理由
パスワードをソースコードや設定ファイルに書くと、コピーされた瞬間から 「誰が持っているか」を制御できなくなります。
Gitの履歴、ビルド成果物、ログ、開発者のPC。秘密が複製される場所が増えるほど、 削除や更新は難しくなります。Secret Managerは値を一か所に集め、アプリには値ではなく 「取得する権限」を渡します。
02 — FOUR LAYERS
金庫を支える
4つの役割
暗号化だけでは、安全なSecret管理にはなりません。
暗号化して保管
保存時は暗号化され、API通信もTLSで保護されます。必要ならCloud KMSのCMEKも利用できます。
利用者の身元を確認
人間だけでなく、Cloud RunやCI/CDにもサービスアカウントなどのIDを割り当てます。
IAMで範囲を制限
Secret単位で読み取りを許可し、プロジェクト内のすべてのSecretへ広げないのが基本です。
操作を追跡
誰がバージョンを追加・無効化・取得したかを監査します。値の取得を記録するにはData Accessログの有効化も確認します。
03 — ACCESS FLOW
アプリが秘密を
受け取るまで
Secret Managerへ接続するための固定パスワードを、アプリへ埋め込まないことが重要です。
アプリは固定キーを持たず、実行環境のWorkload Identityで認証。KMSでエンベロープ復号された秘密ペイロードをメモリ上に直接展開します。
身元を示す
Cloud Runなどの実行環境が、サービスアカウントとして認証する。
→権限を確かめる
そのIDに対象シークレットのペイロードを読む権限があるか判定する。
→値を取り出す
指定されたバージョンを復号し、安全な通信経路で返す。
→操作を記録する
管理操作やデータアクセスをCloud Audit Logsで追跡できる。
production-api → database-password → secretAccessor固定キーを持たず、実行環境のIDを使って取得要求を認証します。
GitHub Actionsなどでは、長期サービスアカウントキーよりWorkload Identity Federationで短時間の認証情報を取得します。
04 — VERSION & ROTATION
値を上書きせず、
Versionを積む
Secretの値はVersionとして不変に保存し、更新時は新しいVersionを追加します。
外部サービス側で新しい認証情報を作る
Secret Managerへ新Versionを追加
アプリをVersion 7へ切り替えて確認
旧Versionを無効化してから破棄
05 — SECRET MANAGER vs KMS
秘密と暗号鍵は
役割が違う
どちらもセキュリティ製品ですが、管理する対象が異なります。
SECRET MANAGER
秘密そのもの
DBパスワードAPIキー
証明書アプリが値を取得して使う
CLOUD KMS
暗号処理の鍵
暗号化・復号署名
鍵の管理データを暗号処理する
Secret Managerの保存データも暗号化されています。追加の制御が必要な場合は、Cloud KMS上の顧客管理鍵（CMEK）を指定できます。
06 — IMPLEMENTATION
実行時にAPIから
取得する
クライアントライブラリは、実行環境に割り当てられたIDを使って認証します。
import { SecretManagerServiceClient }
from "@google-cloud/secret-manager";
const client = new SecretManagerServiceClient();
const [version] = await client.accessSecretVersion({
name: [
"projects/my-project",
"secrets/database-password",
"versions/7",
].join("/"),
});
const password = version.payload?.data?.toString();01AUTH 実行環境のIDを自動利用
02VERSION productionでは番号を固定
03MEMORY 取得後は平文として慎重に扱う
07 — SECURITY BOUNDARY
Secret Managerでも
守れないこと
取得を許可されたプロセス内では、秘密は利用可能な平文になります。
ログへの出力
値、環境変数、エラーオブジェクトを丸ごと出力すると、Cloud Loggingなどへ秘密が残ります。
過剰なIAM権限
プロジェクト全体に対してシークレット閲覧者（Secret Accessor）権限を与えると、そのIDはすべてのシークレットを取得できてしまいます。個別のシークレット単位で権限を付与するのが基本です。
侵害されたアプリ
アプリ自体が侵害されれば、そのアプリに取得が許可されているシークレットも読み取られる可能性があります。
latestへの無条件追従
最新バージョンに不具合があった場合、全インスタンスへ即座に波及します。本番環境ではバージョン番号を明示的に固定し、動作確認の上で段階的に切り替えます。
08 — SAME PATTERN, DIFFERENT CLOUDS
クラウドが変わっても
考え方は同じ
名称は違っても、「Secret・Identity・Policy・Audit」の組み合わせで捉えられます。
IN ONE SENTENCE
Secret Managerとは？
秘密を暗号化して保管し、IDとIAMで必要な相手だけに渡し、その操作を追跡する仕組み。
SOURCES / GOOGLE CLOUD OFFICIAL