Cloud Run IAM roles Stay organized with collections Save and categorize content based on your preferences.
This page lists theIdentity and Access Management (IAM) predefined roles foraccessing Cloud Run resources.
Predefined roles
The following table describes IAM roles that are associated withCloud Run, and lists the permissions that are contained in each role.
Roles can be granted to users on an entire project or on individual services.ReadManaging access using IAM tolearn more.
Roles only apply to Cloud Run services or jobs, they do not applyto Cloud Run domain mappings. TheProject > Editor roleis needed to create or update domain mappings.
| Role | Permissions |
|---|---|
Cloud Run Admin( Full control over all Cloud Run resources. Lowest-level resources where you can grant this role:
|
|
Cloud Run Builder( Can build Cloud Run functions and source deployed services. |
|
Cloud Run Developer( Read and write access to all Cloud Run resources. Lowest-level resources where you can grant this role:
|
|
Cloud Run Invoker( Can invoke Cloud Run services and execute Cloud Run jobs. Lowest-level resources where you can grant this role:
|
|
Cloud Run Jobs Executor( Can execute and cancel Cloud Run jobs. |
|
Cloud Run Jobs Executor With Overrides( Can execute and cancel Cloud Run jobs with overrides. |
|
Cloud Run Service Agent( Gives Cloud Run service account access to managed resources. Warning: Do not grant service agent roles to any principals exceptservice agents. |
|
Cloud Run Service Invoker( Can invoke Cloud Run services. |
|
Cloud Run Source Developer( Deploy and manage Cloud Run source deployed resources. |
|
Cloud Run Source Viewer( View Cloud Run source deployed resources. |
|
Cloud Run Viewer( Can view the state of all Cloud Run resources, including IAM policies. Lowest-level resources where you can grant this role:
|
|
For a reference describing the IAM permissions contained in eachIAM role, refertoCloud Run IAM Permissions.
Custom roles
For developers that want to define their own roles containing bundles ofpermissions that they specify, IAM offerscustom roles.
If the role contains permissions that let a developer deploy services, then youmust perform theadditional configuration below.
Deployment permissions
Cloud Run services and jobs run with aservice identity.
To create or update Cloud Run resources, thedeployer accountmust have access on the following resources:
- The Cloud Run service or job
- The Artifact Registry repository of the service's or job's container image
- The service account used as the service identity
By default, the service identity is the Compute Engine default serviceaccount. However, Google recommends using a user-managed service account withthe most minimal set of permissions. See the service identity configurationpages forservices andjobs for more details.
Select the appropriate expander arrow to learn about the required deploymentpermissions.
Click to view the required roles for deploying services or revisions
To get the permissions that you need to deploy services or revisions, you or your administrator must grant IAM roles to the deployer account on the following resources:
- Cloud Run Developer (
roles/run.developer) on the Cloud Run service - Artifact Registry Reader (
roles/artifactregistry.reader) on the Artifact Registry repository of the container images of the service - Service Account User (
roles/iam.serviceAccountUser) on the Cloud Run service identity
The following permissions are required to deploy services or revisions:
run.services.createto create services andrun.services.updateto update servicesrun.services.getandrun.operations.getto read the status of the serviceartifactregistry.repositories.downloadArtifactson the repository container the container images of the serviceiam.serviceAccounts.actAson the service identity
You might also be able to get these permissions withcustom roles or otherpredefined roles.
Click to view the required roles for executing jobs
To get the permissions that you need to execute jobs, you or your administrator must grant IAM roles to the deployer account on the following resources:
- To create or update a job:Cloud Run Developer (
roles/run.developer) on the Cloud Run job - To execute jobs or cancel job executions:Cloud Run Invoker (
roles/run.invoker) on the Cloud Run job - Artifact Registry Reader (
roles/artifactregistry.reader) on the Artifact Registry repository of the container images of the job - Service Account User (
roles/iam.serviceAccountUser) on the Cloud Run service identity
The following permissions are required to execute jobs:
run.jobs.createto create jobs andrun.jobs.updateto update jobsrun.jobs.runto execute jobsrun.jobs.getandrun.operations.getto read the status of the jobartifactregistry.repositories.downloadArtifactson the repository container the container images of the jobiam.serviceAccounts.actAson the service identity
You might also be able to get these permissions withcustom roles or otherpredefined roles.
Click to view the roles for deploying from source
To get the permissions that you need to deploy a service or job from source code, you or your administrator must grant the following roles:
- Cloud Run Source Developer (
roles/run.sourceDeveloper) to the deployer account on your project. - Service Usage Consumer (
roles/serviceusage.serviceUsageConsumer) on your project - Cloud Run Builder (
roles/run.builder) to the Compute Engine default service account on your project.
If your Cloud Run resource interfaces with Cloud Client Libraries,you must grant IAM roles to the service identity, as required bythe Cloud Client Libraries.
If you are using a cross-project service account todeploy a service, grant the Service Account Token Creator(roles/iam.serviceAccountTokenCreator) role on the service identity. SeeUse service accounts in other projectsfor more details.
To grant the Cloud Run deployer account access, see the followinginstructions:
Console UI
To grant access on theCloud Run resource:
Go to the Cloud Run page in the Google Cloud console:
Select Services or Jobs.
Click the checkbox at the left of the service or job you want to addprincipals to.
In the information pane in the top right corner click thePermissions tab. If the information pane isn't visible, you may needto clickShow Info Panel, then clickPermissions.
ClickAdd principal.
In theNew principals field, enter one or more identities that needaccess to your job.
From theRole drop-down menu, select a role or roles. The roles youselect appear in the pane with a short description of the permissionsthey grant.
ClickSave.
To grant access on theArtifact Registry repository:
Go to the Artifact Registry page in the Google Cloud console:
Click the checkbox at the left of the repository you want to addprincipals to.
In the information pane in the top right corner click thePermissions tab. If the information pane isn't visible, you may needto clickShow Info Panel, then clickPermissions.
ClickAdd principal.
In theNew principals field, enter one or more identities that needaccess this repository.
From theRole drop-down menu, selectArtifact Registry Reader.
ClickSave.
To grant access on theservice identity resource:
Go to theService accounts page of the Google Cloud console:
Select the service account email address you are using as the serviceidentity, either:
- The Compute Engine default service account:
PROJECT_NUMBER-compute@developer.gserviceaccount.com - A service account that was manually created:
SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com
- The Compute Engine default service account:
Click thePermissions tab.
Click theGrant accessbutton.
Enter the principal (e.g. user or group email) that matches the principalyou're granting the Admin or Developer role to.
In theSelect a role drop-down, select theService Accounts >Service Account User role.
ClickSave.
If you are deploying from source, grant access to the deployer account andthe Cloud Build service account on yourproject:
Go to the IAM page in the Google Cloud console:
Select the email address of the principal you are using as the deployeraccount.
Click the edit icon on the left of the principal.
From theRole drop-down menu, selectCloud Run Source Developer.
From theRole drop-down menu, selectService Usage Consumer.
ClickSave.
Select the service account email address you are using as the serviceidentity, either:
- The Compute Engine default service account:
PROJECT_NUMBER-compute@developer.gserviceaccount.com - A service account that was manually created:
SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com
- The Compute Engine default service account:
Click the edit icon on the left of the principal.
From theRole drop-down menu, selectCloud Run Builder.
ClickSave.
gcloud
To grant access on theCloud Run resource, use the
gcloud run services add-iam-policy-bindingor thegcloud run jobs add-iam-policy-bindingcommand, replacing the highlighted variables with the appropriate values:gcloudrunCLOUD_RUN_RESOURCE_TYPENAMEadd-iam-policy-binding\--member="PRINCIPAL"\--role="ROLE"
Replace:
- CLOUD_RUN_RESOURCE_TYPE with the Cloud Runresource type, such as
servicesorjobs. - NAME with the name of the Cloud Run resource.
PRINCIPAL with the deployer account you are adding thebinding for, using the format
user|group|serviceAccount:emailordomain:domain. For example:user:test-user@gmail.comgroup:admins@example.comserviceAccount:test123@example.domain.comdomain:example.domain.com
ROLE with the role name to assign to the deployeraccount. For example,
roles/run.developer.
- CLOUD_RUN_RESOURCE_TYPE with the Cloud Runresource type, such as
To grant access on theArtifact Registry repository, use the
gcloud artifacts repositories add-iam-policy-bindingcommand, replacing the highlighted variables with the appropriate values:gcloudartifactsrepositoriesadd-iam-policy-bindingREPOSITORY\--location="LOCATION"\--member="PRINCIPAL"\--role="roles/artifactregistry.reader"
Replace:
- REPOSITORY with the ID of the repository.
- LOCATION with the location of the repository.
- PRINCIPAL with the deployer account you are adding thebinding for, using the format
user|group|serviceAccount:emailordomain:domain.
To grant access on theservice identity resource, use the
gcloud iam service-accounts add-iam-policy-bindingcommand, replacing the highlighted variables with the appropriate values:gcloudiamservice-accountsadd-iam-policy-binding\SERVICE_ACCOUNT_EMAIL\--member="PRINCIPAL"\--role="roles/iam.serviceAccountUser"
Replace:
SERVICE_ACCOUNT_EMAIL with the service account email addressyou are using as the service identity, such as:
- The Compute Engine default service account:
PROJECT_NUMBER-compute@developer.gserviceaccount.com - A service account that was manually created:
SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com
- The Compute Engine default service account:
PRINCIPAL with the principal you are adding the binding for,using the format
user|group|serviceAccount:emailordomain:domain. For example:user:test-user@gmail.comgroup:admins@example.comserviceAccount:test123@example.domain.comdomain:example.domain.com
If you are deploying from source, grant access to the deployer accountand the Cloud Build service account on yourproject withthe
gcloud projects add-iam-policy-bindingcommand.Grant the Cloud Run Builder role to the build service account on your project:
gcloudprojectsadd-iam-policy-bindingPROJECT_ID\--member=serviceAccount:BUILD_SERVICE_ACCOUNT_EMAIL\--role=roles/run.builder
Replace:
- PROJECT_ID with your Google Cloud project ID.
BUILD_SERVICE_ACCOUNT_EMAIL with the service account emailaddress you are using as the build service account, such as:
- The Compute Engine default service account (default):
PROJECT_NUMBER-compute@developer.gserviceaccount.com. - A service account that was manually created:
SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com.
- The Compute Engine default service account (default):
Grant the Cloud Run Source Developer role to the deployeraccount on your project:
gcloudprojectsadd-iam-policy-bindingPROJECT_ID\--member=PRINCIPAL\--role=roles/run.sourceDeveloper
Replace:
- PROJECT_NUMBER with your Google Cloud projectnumber.
- PROJECT_ID with your Google Cloud project ID.
- PRINCIPAL with the deployer account you are adding thebinding for.
Grant the Service Usage Consumer role to the deployeraccount on your project:
gcloudprojectsadd-iam-policy-bindingPROJECT_ID\--member=PRINCIPAL\--role=roles/serviceusage.serviceUsageConsumer
Replace:
- PROJECT_NUMBER with your Google Cloud projectnumber.
- PROJECT_ID with your Google Cloud project ID.
- PRINCIPAL with the deployer account you are adding thebinding for.
For detailed instructions on how to find your project ID, and projectnumber, seeCreating and managing projects.
In addition to the deployer account needing these permissions, theCloud Runservice agent must havepermissions to access the deployed container. By default, Google grants theCloud Run Service Agentrole to the Cloud Run service agent automatically.
Avoid IAM allow policy limits in automated deployments
When using Infrastructure-as-Code (IaC) tools likeConfig Connector to deploy Cloud Runservices, the deployer account needs permission to read container images fromArtifact Registry. These permissions are enforced by an IAMallow policy, which is attached to the relevantresource (Artifact Registry repository), and specifies which principals have beengranted which roles.
If numerous Cloud Run services are deployed, each with a unique serviceaccount, IaC tools create individual role bindings in the Artifact Registry allowpolicy. This can quickly exceed the1,500-member-per-policylimit, which restricts the number ofprincipals (service accounts or users) listed in a single resource's allowpolicy.
To avoid this limitation, consider using a single service account acrossmultiple services. This minimizes the number of entries in the Artifact Registryallow policy.
Caution:Avoid using groups for granting service accounts access to resources.Optional permissions for Cloud Run users
The following optional permissions can be considered when configuring accountswith minimal permission set:
monitoring.timeSeries.liston the project level. Typically assignedthrough theroles/monitoring.viewerrole. It allows user to accessmetrics generated by their service. For more information, go to theStackdriver documentation forAccess Control.logging.logEntries.liston the project level. Typically assigned throughtheroles/logging.viewerrole. It allows user to access logs generatedby their service. For more information, go to theAccess Control guidein the Stackdriver Logging documentation.
Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2026-02-19 UTC.