【テクニカル・上級編】GCP Workload Identityによるサービスアカウントの権限管理 – アプリケーションセキュリティ & 安全な開発防御ガイド

鍵を捨て、アイデンティティを纏え：Workload Identityの深淵とアーキテクチャの真髄

「キーファイルをPodの中に埋め込む」。数年前まで、これがクラウドネイティブにおける『悪しき慣習』の代名詞だった。環境変数やシークレットボリュームにJSONを忍ばせ、それがログやメモリダンプから漏洩するリスクに怯える。そんな時代はもう過去のものだ。

今日は、GCPにおけるWorkload Identityの設計思想について、単なる「設定手順」ではなく、攻撃者の視点から見た「いかに突破が困難か」という防衛的観点で掘り下げていこう。

1. なぜ「秘密鍵」は脆弱性の温床なのか

JSON形式のサービスアカウントキーを配布するということは、「永続的な認証情報」を攻撃対象領域（Attack Surface）として公開し続けることに他ならない。

攻撃者がコンテナのRCE（リモートコード実行）を成功させた際、真っ先に探索するのは `/var/run/secrets` や環境変数だ。一度キーを奪取すれば、その権限はローカル環境からでも利用可能であり、IAMの監査ログを迂回する可能性すら残る。

Workload Identityは、この「静的な鍵」を「動的な短命トークン」に置き換える。Podのアイデンティティは、Googleのメタデータサーバー（`169.254.169.254`）を介して、GKEノードのブートストラップトークンと関連付けられたK8sサービスアカウントによって動的に証明される。攻撃者がメモリをダンプしたところで、そこにあるのは有効期間の短いJWT（JSON Web Token）のみだ。

2. アーキテクチャの急所：最小権限の「粒度」を極める

多くのアーキテクトが陥る罠は、サービスアカウントの権限を「コンポーネント単位」で広範に定義してしまうことだ。例えば「Backend-SA」にBigQueryへの全アクセス権を与えるのは、セキュリティの観点では「爆弾を抱えたまま走る」に等しい。

Workload Identityの真価を発揮させるには、IAM条件（IAM Conditions）を組み合わせたリソースベースの制御が必須だ。

Kubernetes サービスアカウントの作成
apiVersion: v1
kind: ServiceAccount
metadata:
name: backend-processor
namespace: production
annotations:
# GCPサービスアカウントとの紐付け
iam.gke.io/gcp-service-account: backend-processor@my-project.iam.gserviceaccount.com

さらに、GCP側のIAM設定で以下のような条件を付与する。

特定のBigQueryデータセットのみにアクセスを制限するIAMポリシーの例
gcloud iam service-accounts add-iam-policy-binding \
backend-processor@my-project.iam.gserviceaccount.com \
–role=”roles/bigquery.dataViewer” \
–member=”serviceAccount:backend-processor@my-project.iam.gserviceaccount.com” \
–condition=”expression=resource.name.startsWith(‘projects/my-project/datasets/secure_data’),title=limited_access”

この「条件付きIAM」こそが、万が一アプリケーションがプロンプトインジェクション等で汚染され、悪意あるクエリを実行しようとした際の「最後の防波堤（ガードレイル）」となる。

3. 見えない攻撃：メタデータサーバーへのSSRF

セキュリティアーキテクトとして忘れてはならないのは、Workload Identityの基盤であるメタデータサーバーが、SSRF（サーバーサイドリクエストフォージェリ）のターゲットになり得るという事実だ。

もしPod内で実行されているコードに脆弱性があり、攻撃者が `http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity` を叩ける状態であれば、トークンを盗まれる可能性がある。

防御の要諦：

NetworkPolicyの徹底: 特定のNamespaceやPodから、`169.254.169.254` へのアクセスをデフォルトで遮断し、必要なPodにのみ許可を与える。
ワークロードの分離: 外部からの入力を直接受け取るフロントエンドPodには、可能な限り強力な権限を渡さない。トークンの取得すら制限すべきだ。

4. 未来の脅威：耐量子暗号とIDフェデレーション

現在、我々が利用しているJWTの署名アルゴリズムは、将来的に量子コンピュータによるショアのアルゴリズムの影響を受ける可能性がある。Googleは既に、IAMの基盤において鍵管理のアップグレードを進めているが、設計者としては「IDそのもの」のライフサイクル管理にも意識を向けるべきだ。

Workload Identityは、OIDC（OpenID Connect）ベースのフェデレーションである。これはつまり、GCP外のワークロード（AWSやオンプレミス）とも同じ仕組みで信頼関係を構築できることを意味する。

最後に：監査こそが信頼の証

どんなに堅牢な設計も、監視がなければただの砂上の楼閣だ。以下のメトリクスとログを常に監視せよ。

`cloudaudit.googleapis.com/data_access`: サービスアカウントによる異常なAPIコール頻度。
GKE Workload Identityメトリクス: トークン発行の失敗ログ（不正なアクセス試行の兆候）。

セキュリティとは、境界線を引くことではなく、「境界線が破られた後の世界」をいかに制御し続けるかという思考実験の連続だ。Workload Identityを単なる認証ツールと捉えず、アイデンティティベースのゼロトラストの核心として、泥臭く、かつ冷徹に運用してほしい。

次にシステムをデプロイする際、そのPodが本当に必要な「最小限の権限」で動いているか、自問自答してみるといい。その問いこそが、君を一段上のエンジニアへと引き上げるはずだ。