エンジニア達の「完全に理解した」Talk　#70

続・Google Cloud を完全に理解した エンジニア達の「完全に理解した」Talk #70

自己紹介 akihiko.KIgure a.k.a グレさん 恵比寿とグンマー帝国の 2 拠点でフロントエンド開発をしています。

個人的推しOSS ※アルファベット順 Angular CHIRIMEN Open Hardware Firebase

個人的推しOSS ※アルファベット順 MDN Web Docs Nx Rust

今日テーマ Google Cloud

今日お話する事 ● vol 61,66, 67, 68 のおさらい ● Workload Identity Federation ● デプロイワークフロー実装例

● vol.61 のおさらい

エンジニア達の「完全に理解した」Talk #61 タイトル：Nx を完全に理解した！ ・Angular, Rust, Nx を使ったモノレポ開発の LT です。 スライド Youtube connpass

nx ワークスペース作成例

● vol.66 のおさらい

エンジニア達の「完全に理解した」Talk #66 タイトル：Firebase を完全に理解した！ ・Angular, Rust を Firebase にデプロイする LT です。 スライド Youtube connpass

NG！！！ build Rust Github Action Nx Cloud deploy build Angular

● vol.67 のおさらい

エンジニア達の「完全に理解した」Talk #67 タイトル：Firebase を完全に理解した！ ・Angular を Firebase にデプロイする LT です。 スライド Youtube connpass

deploy build Google Cloud Rust Github Action Nx Cloud deploy build Angular

● vol.68 のお話

エンジニア達の「完全に理解した」Talk #68 タイトル：Google Cloud を完全に理解した！ ・Rust を Cloud Run にデプロイする LT です。 スライド Youtube connpass

手動 deploy OK、CI 経由 deploy が NG！！！ deploy build Google Cloud Rust Github Action Nx Cloud deploy build Angular

システムアクセス図 Artifact Registry Cloud Run Angular Rust

前回何が問題だったか！

？！

もう一つ（最大の理由）

GCP、特に権限周りの設定が 正しく出来ていなかった

？！？！？！

という訳で、解説します！

GitHub Actions と GCP の連携設定 Workload Identity Federation 目的 ● GitHub Actions から GCP リソースに安全にアクセス ● 秘密鍵（Service Account Key）を使わずに認証 ● 特定のリポジトリ・ブランチのみにアクセス権限を制限

Workload Identity Federation のイメージ 目的 GCP のリソース（Cloud Run, Cloud Storage, BigQuery など） を 安全にアクセス できるようにする仕組み。 特徴 「サービスアカウント鍵（JSONファイル）」を配布せずに、 外部サービス（GitHub Actions, AWS, Azure など）から直接 GCP にアクセスできる。

仕組みをざっくり ・外部環境（例: GitHub Actions）が「私は GitHub 上のこのワ ークフローですよ」という 一時的な証明書 を発行する。 ・GCP はその証明書を確認して「OK、この人は許可された GitHub ワークフローだ」と判断する。 ・GCP がその場で 短命の認証トークン（数分〜1時間有効） を発行し、アクセスを許可する。 ・つまり 鍵ファイルを持ち歩かなくて済む。

メリット 秘密鍵の管理不要 → JSON鍵ファイルを GitHub に置く必要がない。 安全性向上 → 漏洩リスクが減り、有効期限つきのトークンで運用できる。 多環境対応 → GitHub Actions, AWS, Azure, など色々な外部環境から GCP に接続できる。 最小権限設計 → 必要な GCP リソースだけに権限を絞れる。

Workload Identity Federation（WIF）の仕組み OIDC（OpenID Connect） 誰がそのリクエストを送っているかを安全に証明するための仕組み

この仕組みを使うためにGoogle Cloud 側で ・Workload Identity プール ・OIDC プロバイダ を設定する必要があります

用語の説明

GCP_PROJECT_ID * 意味 あなたの GCP プロジェクトの「名前」 *例 my-sample-project * 特徴 人間が読んで分かり易いように自由に付けられる文字列 * 使う場面 * コマンド実行 (`gcloud config set project my-sample-project`) * Firebase Hosting の設定 (`projectId`)

PROJECT_NUMBER * 意味 GCP プロジェクトに自動で割り振られる「番号（数字だけ）」。 *例 123456789012 * 特徴 重複しない一意な番号。プロジェクトIDとは違って人間が決められない。 * 使う場面 * Workload Identity Federation でリソースを指定する時 * API の内部識別子として利用

POOL_ID * 意味 Workload Identity Federation の「プール（入れ物）」の名前。 *例 github-pool * イメージ 「このグループは外部IDをまとめる場所ですよ」という箱。 * 使う場面: * GitHub, AWS, Azure など、どの外部環境からアクセスできるかを グループごとに管理

PROVIDER_ID * 意味 プールの中で「どこから来た人か」を区別する ID。 *例 github-provider * イメージ * プール = 大学 * プロバイダー = 学部（工学部, 経済学部…） * 「この学部の学生だけ OK」みたいに細かく条件を付けられる。 * 使う場面 * GitHub Actions の特定リポジトリだけ許可する、など

SERVICE_ACCOUNT * 意味 GCP 内で「ロボットユーザー」みたいなもの。 *例 [email protected] * 特徴 * 人間ではなく、プログラムやCI/CDが使う用のアカウント * 権限（例: Cloud Run へデプロイできる権限など）を付与できる * 使う場面 * GitHub Actions が Cloud Run にデプロイする時 * アプリが Cloud Storage にファイルを保存する時

2. GitHub Secrets に設定する値 ・GCP_PROJECT_ID プロジェクト ID ・GCP_WIF_PROVIDER フルリソース名（プロジェクト番号含む） ・GCP_WIF_SERVICE_ACCOUNT サービスアカウントのメールアドレス

Workload Identity プール プロバイダの設定例

Google Cloud にデプロイする ワークフローの実装例

yaml をしっかり見たい方用 gist

GCP_PROJECT_ID GCP_WIF_PROVIDER GCP_WIF_SERVICE_ACCOUNT

GCP_PROJECT_ID GCP_WIF_SERVICE_ACCOUNT

今回の場合は、バックエンドアプリ名に合わせて backend ビルド中に作成されたタグ名をセット 今回は、アジアのリージョン：asia-northeast1 を指定

ワークフローに使うシークレットキー

動 作 確 認

それぞれデプロイ出来ました。(Google Cloud) Cloud Run に backend がデプロイされている

それぞれデプロイ出来ました。(Firebase) firebase に frontend がデプロイされている

デプロイ環境での動作確認 正しく通信しています

まとめ Google Cloud できるよ にんげんだもの ぐれを

お ま け

vol.61, 67, 68, 70 とお付き合い頂き 誠に有難うございました。

ご静聴ありがとうございました！