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 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, revisions, and jobs run as the service identity. In order to configure the service identity, the deployer account needs access on both the Cloud Run resource and the service identity resource. With access on both resources, the deployer account can create, update, or delete the Cloud Run resource, and attach the service account to the Cloud Run resource.
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:
- Service Account User
(
roles/iam.serviceAccountUser) on your service identity - Cloud Run Developer
(
roles/run.developer) on the Cloud Run service
The following permissions are required to deploy services or revisions:
- To attach a service account to the Cloud Run resource:
iam.serviceAccounts.actAs - To create services:
run.services.create,run.services.update - To read the status of the service:
run.services.get,run.operations.get
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:
-
Service Account User
(
roles/iam.serviceAccountUser) on the Cloud Run service identity - To execute jobs using the Google Cloud CLI:
Cloud Run Invoker
(
roles/run.invoker) on the Cloud Run job - To execute jobs using the Google Cloud console, override job
configurations, cancel job executions:
Cloud Run Developer
(
roles/run.developer) on the Cloud Run job
The following permissions are required to execute jobs:
- To attach a service account to the Cloud Run resource:
iam.serviceAccounts.actAs - To create jobs:
run.jobs.create,run.jobs.update - To run existing jobs:
run.jobs.run - To read the status of the job:
run.jobs.get,run.operations.get
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 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[email protected] - 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 add-iam-policy-binding \ --member="PRINCIPAL" \ --role="ROLE"
Replace:
CLOUD_RUN_RESOURCE with the Cloud Run resource type, such as
servicesorjobs.PRINCIPAL with the deployer account you are adding the binding for, using the format
user|group|serviceAccount:emailordomain:domain. For example:user:[email protected]group:[email protected]serviceAccount:[email protected]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 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[email protected] - 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:[email protected]group:[email protected]serviceAccount:[email protected]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.liston the project level. Typically assigned through theroles/monitoring.viewerrole. It allows user to access metrics generated by their service. For more information, go to the Stackdriver documentation for Access Control.logging.logEntries.liston the project level. Typically assigned through theroles/logging.viewerrole. It allows user to access logs generated by their service. For more information, go to the Access Control guide in the Stackdriver Logging documentation.