Cloud SchedulerのPERMISSION_DENIEDの原因は?
PR

Cloud SchedulerのPERMISSION_DENIEDの原因は?

ERROR 設定・構築・運用
記事内に広告が含まれています。
スポンサーリンク

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

スポンサーリンク
スポンサーリンク

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

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

HTTP ターゲットで認証を使用する  |  Cloud Scheduler Documentation  |  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をたたいて起動することを確認するというのはやっておきましょう。

コメント

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