Access control with IAM

Note: This content applies only to Cloud Run functions—formerly Cloud Functions (2nd gen).

For the 1st gen version of this document, see Access control with IAM (1st gen).

You (that is, the user or service account deploying the function) can set access control using roles at the project level. Grant a role to a project member or service account to determine the level of access to your Google Cloud project and its resources. By default, all Google Cloud projects come with a single user: the original project creator. No other users have access to the project, and therefore, access to functions, until a user is added as a project team member.

Access control for users

You can add users as team members to your project and grant them roles using Identity and Access Management (IAM).

Cloud Run functions supports the basic roles of Editor, Owner, and Viewer, which give the following permissions:

• Editor and Owner: Read and write access to all functions-related resources. Lets users deploy, update, and delete functions. Additional access to other resources in the project.
• Viewer: Read-only access to functions and locations. Lets users list functions and see their details, but does not let them view the source code. Additional access to other resources in the project.

Cloud Run functions also supports the Cloud Run functions predefined Developer and Viewer roles, which give the following permissions:

• Developer: Read and write access to all functions-related resources. Lets users deploy, update, and delete functions. No access to other resources in the project.
• Viewer: Read-only access to functions and locations. Lets users list functions and see their details, but does not let them view the source code. No access to other resources in the project.

Note: To write or access Cloud Run functions logs, a project member must also have the appropriate logging permissions. For more information, see the Cloud Logging access control guide.

Access control for service accounts

A service account is a special type of Google Cloud account that acts as an identity for a non-human user that needs to authenticate and be authorized to access data and perform various actions. Some of these accounts are created and managed by Google itself and are known as service agents.

The following service accounts are used for Cloud Run functions:

Name	Member ID	Role
Compute Engine default service account	[e-mail]	Editor
Google Cloud Run functions Service Agent	[e-mail]	Cloud Run functions Service Agent
—	[e-mail]	Cloud Build Service Account
Cloud Build Service Account	[e-mail]	Cloud Build Service Agent
Google Container Registry Service Agent	[e-mail]	Container Registry Service Agent
Artifact Registry Service Agent	[e-mail]	Artifact Registry Service Agent

Note:

The iam.automaticIamGrantsForDefaultServiceAccounts organization policy constraint prevents the Editor role from being automatically granted to default service accounts. If you created your organization after May 3, 2024, this constraint is enforced by default.

We strongly recommend that you enforce this constraint to disable the automatic role grant. If you disable the automatic role grant, you must decide which roles to grant to the default service accounts, and then grant these roles yourself.

If the default service account already has the Editor role, we recommend that you replace the Editor role with less permissive roles. To safely modify the service account's roles, use Policy Simulator to see the impact of the change, and then grant and revoke the appropriate roles.

Runtime service accounts

At runtime, Cloud Run functions defaults to using the Compute Engine default service account ([e-mail]), which also has the Editor role on the project. You can change the roles of these service accounts to limit or extend the permissions for your running functions. You can also change which service account is used by providing a non-default individual service account.

To learn more about service accounts, see the service accounts documentation.

Note: Authenticating as the runtime service account from inside your function might fail if you change the Cloud Run functions service account's permissions.

Administrative service accounts

To perform administrative actions on your project during the creation, updating, or deletion of functions, all projects in Cloud Run functions require the Google Cloud Run functions Service Agent service account ([e-mail]).

In addition, all runtimes carry out container image building and storage within your project. To support this, you also need to provision the following:

• The basic Cloud Build service account ([e-mail])
• The Cloud Build Service Agent service account ([e-mail])
• The Google Container Registry Service Agent service account ([e-mail])

These service accounts should have the roles listed in the earlier table.

Google Cloud Run functions Service Agent service account

By default, the Google Cloud Run functions Service Agent service account ([e-mail] has the cloudfunctions.serviceAgent role on your project.

Warning: If you remove the default role binding or modify the permissions granted to the Cloud Run functions Service Agent service account on your Google Cloud project, the Cloud Run functions create, update, and delete operations might fail.

Here's a few of the notable permissions that the cloudfunctions.serviceAgent uses:

Permission	Description
roles/artifactregistry.admin	Manage repositories and store build images in Artifact Registry.
roles/cloudbuild.builds.editor	Required to use Cloud Build to perform builds in user project.
roles/cloudbuild.customworkers.builder	Create builds in Cloud Build custom workers.
compute.globalOperations.get, compute.networks.access, vpcaccess.connectors.{get, use}	Provision functions with access to the consumer projects VPC.
roles/eventarc.developer	Manage Eventarc triggers for functions.
firebasedatabase.instances.{get, update}	Create functions triggered by the Firebase Realtime Database.
iam.serviceAccounts.{actAs, getAccessToken, signBlob}	Ability to get runtime service account credentials.
iam.serviceAccounts.getOpenIdToken	Needed for the agent to get an OpenID token on a user-specified authority. OpenID token is used for invoking IAM-enabled functions.
pubsub.subscriptions	Manage subscriptions in the user's project.
pubsub.topics	Manage topics in the user's project.
roles/run.developer	Manage the Cloud Run Service for functions.
storage.buckets.create, storage.objects.{delete, get, create, list}	Required for storing source code in user project.

You can see the entire set of permissions under the predefined IAM roles or by running this command:

gcloud iam roles describe roles/cloudfunctions.serviceAgent

You can reset this service account to the default role by removing whatever role it has and adding the Cloud Run functions Service Agent role:

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member serviceAccount:[e-mail] \
  --role roles/cloudfunctions.serviceAgent

Troubleshooting permission errors

If you get permission errors when you deploy, update, delete, or execute functions in your project, perform the following steps:

1. Make sure that you have the Editor or Owner role on your project, or that you are using the Cloud Run functions Developer role.

   If you are using the Cloud Run functions Developer role at the project level, also ensure that you have granted the user the IAM Service Account User role.

   Currently, only execution permissions are allowed at the per-function level.

2. Verify that the Cloud Run functions Service Agent service account ([e-mail]) has the cloudfunctions.serviceAgent role for your project.

   Make sure the Include Google-provided role grants box on the Permissions tab of the Console IAM page is checked to see this account. Or you can use gcloud projects add-iam-policy-binding PROJECT_ID.

3. Ensure that you have permissions for trigger sources, such as Pub/Sub or Cloud Storage.

If you get an ”insufficient permissions” error, or have other authentication problems when you run your functions, make sure that the runtime service account has the correct permissions to access the resources your functions need. Then, repeat steps 2 and 3.

If you get a ”service unavailable” error during deployment, make sure that the runtime service account [e-mail] exists in your project. To recreate this service account if it was deleted, see Undeleting a service account.

See also Troubleshooting Cloud Run functions.