Cloud Run functionsのデプロイに関する権限まとめ

本投稿は TECOTEC Advent Calendar 2025 の23日目の記事です。

こんにちは。システム開発第一事業部の武田です。普段はエンジニアとしてフロントエンドやバックエンドのシステム開発を行っております。

この記事ではGCP（Google Cloud Platform）を用いたシステムでCloud Run functions（第二世代）を扱う上での権限周りの整理を行います。 主にHttpトリガーやPub/Subトリガーで利用する際の整理になります。

GCPについて

GCPとは、Googleが提供するクラウドサービスを総称したもののことです。Gmailや検索エンジン、YouTubeといったGoogleのサービスで実際に使用されているクラウド基盤を自身のプロジェクトで利用することができます。 私はバックエンドでGCPのCloud Runを使用しています。Cloud Runはスケーリングを自動で行ってくれ、インフラの管理もやってくれるため機能の作成に集中することができ、とても重宝しています。

Cloud Run functionsについて

Cloud Run functionsはイベントをトリガーにして発火するサービスです。基本的にバックエンドはCloud Runで動作させているのですが、非同期で動かしたい時や処理の重い機能を実装したい時にCloud Run functionsを利用しています。 開発中にメイン動作とは別で裏側で動作させたい時や、処理が重くメモリに負担をかけてしまう時がどうしても出てきますよね。そんな時はCloud Run functionsに処理をさせて分担させましょう。Cloud Run functionsの第二世代はCloud Run上で動作していることもあり、料金に関してもCloud Runで動作させた時と同じものになります。処理を分担させたとしても料金の負担が増える心配があまりないため、安心して使用できますね。

Cloud Run functionsの権限周りの整理

Cloud Run functions（第二世代）を扱う上で権限を設定しておかなければ、デプロイに失敗したり動作しなかったりします。 以下、CICDでCloud Run functionsのデプロイ（gcloud functions deploy）を行った際に注意した権限周りのポイントを紹介します。

デプロイに必要な権限

Cloud Run functionsは裏側で、Cloud Run・Eventarc・Artifact Registryなど複数のサービスが連携して動作しています。そのため、デプロイ時に関連する権限も必要になってきます。

デプロイ時に使用するサービスアカウントに必要となる権限

権限名 解説
サービス アカウント ユーザー
roles/iam.serviceAccountUser 		サービスアカウントの使用権限
Cloud Functions 開発者
roles/cloudfunctions.developer 		Cloud Run functionsの作成・更新・削除を行う権限
Artifact Registry 書き込み
roles/artifactregistry.writer 		ビルドされたコンテナイメージを保存する権限

ここで、Cloud Functions 開発者の代わりにCloud Functions 管理者の権限であってもデプロイすることができます。Cloud Functions 管理者はCloud Functions 開発者の権限の内容を内包しているイメージですね。 Artifact Registry 書き込みの代わりにArtifact Registry リポジトリ管理者でも動作するのも同様です。

  • Cloud Functions 管理者：roles/cloudfunctions.admin
    • Cloud Functions 開発者に加えて、アクセス権に関わる権限も有する
      • 他のユーザーに権限を付与できる
      • Cloud Run functions（第一世代）を一般公開できる

次にHttpトリガー、Pub/Subトリガーで利用する際に必要な権限を紹介します。

Httpトリガー

基本的に認証が必要な形でデプロイする場合、追加で必要な権限はありません。しかし、認証なしで公開したい場合、以下の権限が追加で必要になります。

権限名 解説
Cloud Run 管理者
roles/run.admin 		Cloud Run 開発者の権限に加えて、セキュリティやドメインの設定を行う権限

Cloud Run functions（第二世代）は内部的にはCloud Runが動作しています。そのため、一般公開するためにCloud Run 管理者の権限が必要になってくることになります。

Pub/Subトリガー

トピックについてはコンソールで作成するようにすれば、特に追加の権限は必要ありませんがトピックの作成も行う場合、以下の権限が必要になります。

権限名 解説
Pub/Sub 編集者
roles/pubsub.editor 		トピックの作成や管理を行う権限

また、権限ではありませんがEventarc APIを有効にする必要があります。私はこの設定を忘れて、とても苦労しました。。。 Pub/Subの機能とCloud Run functionsをEventarcでリンクさせることができ、Eventarc APIを有効にしないと、Cloud Run functionsで設定したトピックがPub/Subで作成したトピックとリンクすることなく、エラーになってしまいます。Eventarc APIを有効にすることなしでもリンクさせることできるらしいですが、Eventarcがそれを内部的に補完してくれているため手間が無くなりますね。

デッドレタートピックによって、別の処理発火させる際にも注意するポイントがあります。 Pub/Sub サービス アカウントにPub/Sub パブリッシャーとPub/Sub サブスクライバーの権限付与です。Cloud Runで使用する上でのサービスアカウントではなく、Pub/Subシステムのサービスアカウントがあり、そこに権限の付与が必要になります。デッドレタートピックはこちら側で発火制御しておらず、Pub/Subシステム内で実行してもらうため送受信の権限を与えないと動作できないイメージです。

発火させる上で必要な権限

バックエンド（Cloud Run）からCloud Run functionsの処理を発火させて使用する場面を想定しています。そこで、バックエンドで使用しているサービスアカウントにどんな権限が必要か紹介します。

権限名 解説
Cloud Run 起動元
roles/run.invoker 		Cloud Runの関数を実行できる権限
Pub/Sub パブリッシャー
roles/pubsub.publisher 		Pub/Sub のトピックにメッセージを送ることができる権限

Cloud Run functions（第二世代）は内部的にCloud Runであるため、Cloud Runの権限が必要になってきます。 また、Pub/Subトリガー使用時には関数を発火させるためにメッセージを送る必要があります。その時に、Pub/Sub パブリッシャー権限が無いとCloud Run functionsまでメッセージを届けることができなくなります。

まとめ

Cloud Run functionsのデプロイや使用時に必要な権限周りについて整理させていただきました。プロジェクトの構成や使用する機能の違いにより必要な権限は変わってくることもあると思いますので、都度整理し最適な設定を心がけていきたいですね。

テコテックの採用活動について

テコテックでは新卒採用、中途採用共に積極的に募集をしています。
採用サイトにて会社の雰囲気や福利厚生、募集内容をご確認いただけます。
ご興味を持っていただけましたら是非ご覧ください。 tecotec.co.jp