This page lists the Identity and Access Management (IAM) predefined roles for accessing Cloud Run resources.
Predefined roles
The following table describes IAM roles that are associated with Cloud 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. Read Managing access using IAM to learn more.
Roles only apply to Cloud Run services or jobs, they do not apply
to Cloud Run domain mappings. The Project > Editor
role
is needed to create or update domain mappings.
Cloud Run roles |
Permissions |
Cloud Run Admin( Full control over all Cloud Run resources. Lowest-level resources where you can grant this role:
|
|
Cloud Run Builder Beta( 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 excute and cancel Cloud Run jobs. |
|
Cloud Run Jobs Executor With Overrides( Can excute and cancel Cloud Run jobs with overrides. |
|
Cloud Run Service Invoker( Can invoke Cloud Run services. |
|
Cloud Run Source Developer Beta( Deploy and manage Cloud Run source deployed resources. |
|
Cloud Run Source Viewer Beta( 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 each IAM role, refer to Cloud Run IAM Permissions.
Custom roles
For developers that want to define their own roles containing bundles of permissions that they specify, IAM offers custom roles.
If the role contains permissions that let a developer deploy services, then you must perform the additional configuration below.
Deployment permissions
Cloud Run services and jobs run with a service identity.
To create or update Cloud Run resources, the deployer account must have access on the following resources:
- The Cloud Run service or job
- The Artifact Registry repository of the service or job's container image
- The service account used as the service identity
By default, the service identity is the Compute Engine default service account. However, Google recommends using a user-managed service account with the most minimal set of permissions. See the service identity configuration pages for services and jobs for more details.
Select the appropriate expander arrow to learn about the required deployment permissions.
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 your service identity
The following permissions are required to deploy services or revisions:
run.services.create
to create services andrun.services.update
to update servicesrun.services.get
andrun.operations.get
to read the status of the serviceartifactregistry.repositories.downloadArtifacts
on the repository container the container images of the serviceiam.serviceAccounts.actAs
on the service identity
You might also be able to get these permissions with custom roles or other predefined 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 service -
Service Account User
(
roles/iam.serviceAccountUser
) on the Cloud Run service identity
The following permissions are required to execute jobs:
run.services.create
to create jobs andrun.services.update
to update jobsrun.jobs.run
to execute jobsrun.jobs.get
andrun.operations.get
to read the status of the jobartifactregistry.repositories.downloadArtifacts
on the repository container the container images of the service
You might also be able to get these permissions with custom roles or other predefined roles.
If your Cloud Run resource interfaces with Cloud Client Libraries, you must grant IAM roles to the service identity, as required by the Cloud Client Libraries.
To grant the Cloud Run deployer account access, see the following instructions:
Console UI
To grant access on the Cloud 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 add principals to.
In the information pane in the top right corner click the Permissions tab. If the information pane isn't visible, you may need to click Show Info Panel, then click Permissions.
Click Add principal.
In the New principals field, enter one or more identities that need access to your job.
From the Role drop-down menu, select a role or roles. The roles you select appear in the pane with a short description of the permissions they grant.
Click Save.
To grant access on the Artifact 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 add principals to.
In the information pane in the top right corner click the Permissions tab. If the information pane isn't visible, you may need to click Show Info Panel, then click Permissions.
Click Add principal.
In the New principals field, enter one or more identities that need access this repository.
From the Role drop-down menu, select Artifact Registry Reader.
Click Save.
To grant access on the service identity resource:
Go to the Service accounts page of the Google Cloud console:
Select the service account email address you are using as the service identity, 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 Permissions tab.
Click the
Grant access button.Enter the principal (e.g. user or group email) that matches the principal you're granting the Admin or Developer role to.
In the Select a role drop-down, select the Service Accounts > Service Account User role.
Click Save.
gcloud
To grant access on the Cloud Run resource, use the
gcloud run services add-iam-policy-binding
or the
gcloud run jobs add-iam-policy-binding
command,
replacing the highlighted variables with the appropriate values:
gcloud run CLOUD_RUN_RESOURCE_TYPE NAME add-iam-policy-binding \ --member="PRINCIPAL" \ --role="ROLE"
Replace:
- CLOUD_RUN_RESOURCE_TYPE with the Cloud Run resource
type, such as
services
orjobs
. - NAME with the name of the Cloud Run resource.
PRINCIPAL with the deployer account you are adding the binding for, using the format
user|group|serviceAccount:email
ordomain:domain
. For example:user:test-user@gmail.com
group:admins@example.com
serviceAccount:test123@example.domain.com
domain:example.domain.com
ROLE with the role name to assign to the deployer account. For example,
roles/run.developer
.To grant access on the Artifact Registry repository, use the
gcloud artifacts repositories add-iam-policy-binding
command, replacing the highlighted variables with the appropriate values:
gcloud artifacts repositories add-iam-policy-binding REPOSITORY \ --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 the
binding for, using the format
user|group|serviceAccount:email
ordomain:domain
.
To grant access on the service identity resource, use the
gcloud iam service-accounts add-iam-policy-binding
command,
replacing the highlighted variables with the appropriate values:
gcloud iam service-accounts add-iam-policy-binding \ SERVICE_ACCOUNT_EMAIL \ --member="PRINCIPAL" \ --role="roles/iam.serviceAccountUser"
Replace:
SERVICE_ACCOUNT_EMAIL with the service account email address you 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:email
ordomain:domain
. For example:user:test-user@gmail.com
group:admins@example.com
serviceAccount:test123@example.domain.com
domain:example.domain.com
In addition to the deployer account needing these permissions, the Cloud Run service agent must have permissions to access the deployed container. By default, Google grants the Cloud Run Service Agent role to the Cloud Run service agent automatically.
Optional permissions for Cloud Run users
The following optional permissions can be considered when configuring accounts with minimal permission set:
monitoring.timeSeries.list
on the project level. Typically assigned through theroles/monitoring.viewer
role. It allows user to access metrics generated by their service. For more information, go to the Stackdriver documentation for Access Control.logging.logEntries.list
on the project level. Typically assigned through theroles/logging.viewer
role. It allows user to access logs generated by their service. For more information, go to the Access Control guide in the Stackdriver Logging documentation.