した。コードはこれ。
思い出せる限りにやったこと。
GCP
1. Project 新規作成
2. SA 作成、Artifact Registry Writer Role を付与する。
ミニマムだと artifactregistry.repositories.uploadArtifacts があればいいはず。
3. Workflow Identity Federation の設定
この記事を参考に、GitHub Actions の ID 連携の設定 セクションで CLI でやってる部分を GUI でいれていった。
プールを1つ作って、プロバイダはこんな感じで作った。
4. Service Account に WIF provider
#!/bin/bash
PROJECT_ID="hello-cloudrun-111111"
gcloud iam service-accounts add-iam-policy-binding "ci-build@${PROJECT_ID}.iam.gserviceaccount.com" \
--project="${PROJECT_ID}" \
--role="roles/iam.workloadIdentityUser" \
--member="principalSet://iam.googleapis.com/projects/222222222222/locations/global/workloadIdentityPools/github-actions/attribute.repository/chaspy/hello-cloudrun"
これは CLI で設定。これで subject を指定することで repository を絞った。
GitHub Actions
5. Secret 追加
GCP_PROJECT_ID と GCP_WIF_ID の2つを secret にした。別に見えてもいいような気もしつつ。
6. GitHub Actions を書く
使ってる Actions はこれら。
workflow 定義ははこれをみてくれ。
artifact registry はこの辺見て動かした。
ハマったこと
gcloud auth configure-docker asia-northeast1-docker.pkg.dev の部分で指定する region を間違っていて、push が永遠に成功しなかったが、permission がない、としか言われず原因がわからずハマった。ハマるときは絶対に凡ミスなのである。
復習
WIF (Workload Identity Federation) とはなんなのか
GCP 上の IAM を他の Provider から使う仕組みのこと。
AWS および OIDC をサポートしている。
これによって Service Account Key を発行せず、短命の Key を都度発行して認証することができるため、セキュリティ上のリスクを大きく減らすことができる。
テクい例がこちら。
OIDC(OpenID Connect) とはなんなのか
なんらかの認証情報によって認証されたユーザに対して、ID トークンを払い出す仕様が標準化されたもの。これによって1度認証すればその ID トークンを「連携」することができる。
OAuth 2.0 に乗っかって動く。
OAuth 2.0 とはなんなのか
なんらかのリソースを操作、あるいは API 実行などを行うためのアクセストークンを要求する方法と応答を標準化したもの。
RFC6749 は読んでないけどだいたいそんな感じ。
JWT とはなんなのか
JSON Web Token のこと。
JSON で、署名ができるので改善確認ができるトークンの仕様で、OAuth で発行されるトークンとして使われる。
GitHub Actions が OIDC をサポートしたとはどういうことなのか
そのままであるが、OIDC Provider の機能を持ち、Issuer として token の要求あるいは検証ができるようになったため、対応できる Cloud Provider と ID 連携が可能となった。
つまり
- GitHub Actions の OIDC サポート、および GCP Workload Identity Federation が OIDC をサポートしていることにより、GitHub Actions から Keyless で GCP Resource にアクセス可能になった
めでたしめでたし。
CloudRun をデプロイしようとしてただけなんだがおかしいな...
