Cloud Runのdeployでiam.serviceAccounts.actAsが拒否されたら、「誰が」「どのservice accountを」「何の操作で使おうとしたか」を確認します。Cloud Runの実行中にAPIへアクセスする権限と、deploy時にservice accountをservice identityとして付ける権限は別です。
この記事はCloud Runサービスの作成・更新時のactAs診断です。以下の主体とprojectは架空例で、Google Cloudへの接続、IAM閲覧・付与・削除、service account作成、deploy、課金操作は行っていません。role名を列挙するだけでなく、付与先と対象resourceを判断する手順として扱います。
目次
エラーの主体・対象・操作を一組にする
エラー全文と発生時刻、Cloud Runのproject・region・service、要求したruntime service accountを記録します。実行主体がローカル利用者かCIのservice accountか、impersonation後の主体かを照合します。普段Consoleで見ている利用者と同じとは限りません。
表は横にスクロールできます
| 項目 | 架空の確認内容 | 取り違えると起きること |
|---|---|---|
| deployer | CI用の実行主体A | 自分へroleを付けてもCIは変わらない |
| service identity | app実行用service account B | 別SAへの許可では対象を満たさない |
| 対象project | Cloud Runを作るproject X | 別projectのroleを見てしまう |
| SAの所属project | Bが存在するproject Y | cross-project条件を見落とす |
CIで認証が成功したことは、actAsも許可された証拠にはなりません。読める範囲の実行記録や監査ログで主体を確認し、ログにaccess tokenや鍵、認証設定全文を貼らないようにします。
deployerとruntimeの役割を分ける
Cloud Runのservice identity資料（新しいタブで開く）は、service accountがresourceである面とprincipalである面を分けています。deployerはそのresourceをserviceへ付ける権限を持ち、実行時にはservice account自身が必要なGoogle Cloud APIの操作権限を持つ、という二段です。
表は横にスクロールできます
| 失敗段階 | 必要条件の方向 | actAsとの関係 |
|---|---|---|
| service identityを付けるdeploy | deployer→対象SAの利用権限 | actAsを確認する対象 |
| Cloud Runの作成・更新 | deployerのCloud Run操作権限 | actAsだけで全操作は許可されない |
| 実行中のStorage等アクセス | runtime SA→対象resource | actAsの付与とは別 |
| access token取得の別エラー | 表示permissionとservice agent等 | actAsと同じroleで修復しない |
公式資料では、対象service account上のService Account User role（roles/iam.serviceAccountUser）がactAsを含むと説明しています。対象resourceはservice identityに使うSA、付与されるprincipalはdeployerです。runtime SA自身へ別APIのroleを追加するだけでは、この関係は変わりません。
SAが存在し、意図したものかを確認する
エラーに「or it may not exist」が含まれる場合、権限不足と不存在を文字列だけで決めません。設定したSAのemail、project、既定SAかuser-managed SAか、削除されていないかを権限のある管理経路で確認します。名前が似ている別SAを新規作成して埋め合わせる手順にはしません。
表は横にスクロールできます
| 観測 | 次の確認 | 直ちに行わないこと |
|---|---|---|
| CIが想定外のSAを指定 | deploy設定・入力値・既定値 | 想定外SAへ権限追加 |
| SAが見えない | 存在・閲覧権限・所属project | 不存在と断定 |
| 別projectのSA | cross-project要件 | org policyの無効化 |
| 対象も主体も正しい | 対象SAのIAM条件と拒否理由 | project全体へ広いrole付与 |
既定Compute Engine SAが削除されたケースも、Cloud Runのtroubleshootingに説明があります。既定を使う設計なのか、専用SAを指定すべきなのかを確認し、過去の既定権限をすべて戻す方法で直さないようにします。
許可が必要なら対象SAに範囲を絞る
主体と対象が正しく、設計上そのdeployerがそのSAを付ける必要があると確認できたら、管理者が対象SA上の必要なroleを検討します。Consoleでは対象SAのアクセスを持つprincipalの設定を確認し、principal、role、条件、対象resourceの四点を記録します。project全体のOwnerやEditorを、エラーを消すために追加しません。
actAsを持つdeployerがそのSAを実行環境へ付けられることの影響も考慮します。SAに強い実行権限があるなら、利用を許可するdeployerの範囲もそれに対応する必要があります。最小の付与範囲と既存のIAM条件を、担当者が確認します。
service accountが別projectにある場合は、公式資料が示すCloud Run service agentの権限や組織ポリシーなど、追加条件を確認します。別種のpermissionエラーへ変わったら新しい段階として調査し、同じroleの追加を繰り返しません。
修正後の確認と戻し方を記録する
- 変更前のprincipal・role・条件・resourceを記録する。
- 誤った設定値なら、IAM付与より先に正しいservice identity指定へ直す。
- 必要なIAM変更だけを管理者の手順で適用する。
- 同じdeployer・対象SA・projectの検証経路で再確認する。
- deployが進んだことと、実行時APIの最小操作が通ることを分けて確認する。
- 不要だった追加bindingは、既存の必要bindingと区別して取り消せるようにする。
反映確認で失敗しても、同じ許可を複数箇所へ追加する前に、最新エラーのprincipal、permission、resourceを取り直します。role変更が不要だった場合は、今回加えた差分だけを戻し、元から必要な権限をまとめて削除しません。
復旧完了は「広いroleでdeployできた」ではなく、意図した主体が意図したSAだけを使い、必要なCloud Run操作とruntime操作をそれぞれ説明できる状態です。実施していないdeployやAPI確認は未検証として残します。