1. はじめに
本記事は、新卒エンジニアが AWS Lambda から GCP にアクセスできるようになるまでの学習と実装の記録です。
具体的な設定手順を細かく解説する記事というよりも、どのようなサービスが登場し、どんな流れで連携が成立しているのかという全体像の理解を目的としています。
筆者について
- 新卒1年目エンジニア
- AWS SAA（Solutions Architect – Associate）取得済
- AWS 実務経験なし
- GCP 未経験
正直なところ、最初は次のような状態でした。
AWS は少し分かるけれど、GCP は用語から分からない
それでも最終的に、※AWS Lambda から GCP の API を呼び出す構成を経験できたため、その過程を初学者目線でまとめます。
※正確には、「Lambda → AWS の身分証明 → GCP 側で検証 → 一時的に権限借用」
2. マルチクラウドについて
今回の構成はいわゆる マルチクラウド です。
マルチクラウドとは
AWS と GCP のように複数のクラウドサービスを組み合わせて使う構成のこと。
今回のケースでは、
- 処理の起点：AWS Lambda
- データの保存・分析先：GCP（BigQuery / Cloud Storage）
という役割分担になっていました。
最初の疑問
AWS から GCP ってどうやって認証するの？
クラウドが違うのに本当にアクセスできるの？
ここが、最初につまずいたポイントでした。
3. AWS を使って GCP にアクセスするとはどういうことか
今回実装した仕組みは、Workload Identity Federationです。
これは、簡潔にいうと、、、
AWS が自分の身分を証明し、
GCP が信頼できると判断した場合のみ、
一時的に GCP の権限を貸す仕組み
になります。
主に使われる判定要素
-
AWS アカウント
→IDどの AWS アカウントからのアクセスか -
IAM ロール ARN
→どの IAM ロールで実行されているか -
AWS STS の GetCallerIdentity 情報
→AWS によって正規の実行主体であると証明された情報 -
audience（aud）
→この認証情報が「どの宛先向けに発行されたものか」
GCP 側では、これらの属性を
Workload Identity Poolという
どの外部IDを信用するのかを、設定であらかじめ定義した条件と突き合わせ、
すべて一致した場合のみ「信頼できる 外部ID（AWS）」だと判断
し、一時的に貸すという構造になっています。
4. Lambda はどのようにして GCP にアクセスしているのか
Workload Identity Federation を、
ここでは「実際に何が起きているか」という観点で整理します。
ここで重要なのは、
Lambda が直接 GCP の権限を持つわけではない
という点です。
当初の私は、Lambda関数にGCPの権限を持たせて、GCPと連携すると思っていました、、
サービスごとに整理する
この仕組みは、Lambda / AWS / GCP がそれぞれ役割を分担することで成り立っています。
Lambda 関数は何を持っているか
- GCP の権限は 一切持っていない
- AWS の IAM ロール だけを持って実行される
Lambda は「GCP にログインする存在」ではなく、
AWS の IAM ロールで動いているプログラムにすぎません。
AWS は何を持っているか
- IAM ロールの定義
- そのロールを第三者に証明する AWS STS
AWS STS は、
- AWS アカウント ID
- IAM ロール ARN
- 実行主体が正規であること
を 外部（GCP）に証明できる存在です。
GCP は何を持っているか
- 信頼可否を判断する 主導権
- Workload Identity Pool / Provider の設定
- 自身の サービスアカウント権限
GCP は、AWS から送られてきた情報をそのまま信用するのではなく、
事前に定義した条件と一致しているか
を検証し、
- 問題なければ
- 自分のサービスアカウント権限を
- 一時的に貸す
という判断を行います。
実際の起動時の流れ
上記の役割分担を踏まえると、
Lambda 起動時には次のような流れになります。
- Lambda が起動（AWS の IAM ロールで実行）
- Workload Credential JSON を読み込む ※後ほど補足
- AWS STS が一時的な認証情報を発行
- Google STS（Google Cloudのセキュリティトークンサービス）に認証情報を送信
- Workload Identity Pool の条件と照合
- GCP サービスアカウントの権限を一時的に借用
- Google のアクセストークンを取得
- GCP API（BigQuery など）を呼び出す
※Workload Credential JSONとは、
「GCP にどうやって認証しに行くか」を書いた設定ファイルのことを指します。
まとめると、
- Lambda：AWS の IAM ロールで動いているだけ
- AWS：実行主体を第三者に証明する
- GCP：信頼可否を判断し、自分の権限を貸す
つまり、
Lambda → AWS の権限 → Google による検証 → GCP の権限を一時的に利用
という 段階的な権限委譲 が行われています。
まとめ
- 新卒・GCP 未経験でも、AWS の知識があれば理解できる
- 鍵を使わない認証は最初は難しく見える
- 全体の流れを先に理解すると、一気に腑に落ちる
同じように、「AWS は多少わかるけれど、GCPは不安、LambdaでGCPと連携したい」 という方の参考になれば幸いです。
参考資料
GCP 公式ドキュメント
WorkloadIdentityを用いたAWS連携
画像引用元 Workloakload Identity連携