Cloud SchedulerのPERMISSION_DENIEDの原因は?

Cloud SchedulerのPERMISSION_DENIEDの原因は?

ERROR設定・構築・運用

GCPで、Cloud SchedulerとCloud Runの組み合わせで定期的に処理を行おうとしてトラぶったので、メモしておきます。「呼び出し元」「呼び出し先」の2つの権限を考えないといけないので、状況を整理しながら進めましょう。

デフォルトのCloud Schedulerサービスアカウントはある?

Cloud Schedulerのサービスアカウントがないことがあるようですので、確認しておきましょう。

HTTP ターゲットでの認証の使用  |  Cloud Scheduler のドキュメント  |  Google Cloud

昔からあるGCP Projectでなければ、この点は大丈夫でしょう。一応、IAMの管理コンソールで該当するメールアドレスのサービスアカウントが存在しているか、検索しておきましょう。

ジョブの定義(Cloud Scheduler)のサービスアカウントには「Cloud Run起動元」ロールが必要

Cloud Schedulerのジョブを定義するとき、サービスアカウントを指定します。このサービスアカウントに「Cloud Run起動元」のRoleを割り当てておく必要があります。IAMの画面で、割り当てられているRoleを確認しましょう(サービスアカウントの画面だと確認できません)。

Cloud Runのトリガー

gcloud beta run deploy ...

でビルドとデプロイすると気が付きません(認証については聞かれます)が、Cloud RunをキックするためのHTTPリクエストに関して、設定を確認しておきましょう。

Ingressは「すべてのトラフィック…」になっていること。そして、「認証が必要」になっていること。認証なし(未認証の呼び出しを許可)だと、Cloud Schedulerで設定したサービスアカウントが使われるタイミングってあるの?ってことになるので、確認しておきましょう。

これでもダメだったら?

頑張ってください(笑)。ググっても解決につながりそうな記事ってほとんどないので、ぜひ、ブログにまとめてください。

一応、Cloud Runを実行するときのサービスアカウントとClud Schedulerのサービスアカウントが別でも、動いています。ので、この部分は気にする必要はありません。

切り分けのため、Cloud Runのトリガーで認証を「未認証の呼び出しを許可」にして、URLをたたいて起動することを確認するというのはやっておきましょう。

この記事へのコメント

Loading Facebook Comments ...

No Trackbacks.

タイトルとURLをコピーしました