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 Developer( Read and write access to all Cloud Run resources. Lowest-level resources where you can grant this role:
|
|
Cloud Run Invoker( Can invoke a Cloud Run service. Lowest-level resources where you can grant this role:
|
|
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
A user needs the following permissions to deploy new Cloud Run services, service revisions or jobs, as noted:
- For jobs and services,
iam.serviceAccounts.actAs
for the Cloud Run runtime service account. By default, this isPROJECT_NUMBER-compute@developer.gserviceaccount.com
. The permission is typically assigned through theroles/iam.serviceAccountUser
role. - For services,
run.services.create
andrun.services.update
on the project level are required.run.services.get
andrun.operations.get
are not strictly required, but are recommended in order to read the status of the service. Typically assigned through theroles/run.admin
role. It can be changed in the project permissions admin page. - For jobs,
run.jobs.create
andrun.jobs.update
on the project level are required to create Cloud Run jobs with custom roles. To run existing jobs,run.jobs.run
on an individual job is sufficient.run.jobs.run
can be set at the job level or the project level.run.jobs.get
andrun.operations.get
are not strictly required, but are recommended in order to read the status of the job.
To assign the IAM Service Account User role on the Cloud Run runtime service account:
Console UI
Go to the Service accounts page of the Google Cloud console:
Click the email address of the Runtime Service Account (
PROJECT_NUMBER-compute@developer.gserviceaccount.com
).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 dropdown, select the Service Accounts > Service Account User role.
Click Save.
gcloud
Use the gcloud iam service-accounts add-iam-policy-binding
command, replacing the highlighted variables with appropriate values:
gcloud iam service-accounts add-iam-policy-binding \ PROJECT_NUMBER-compute@developer.gserviceaccount.com \ --member="PRINCIPAL" \ --role="roles/iam.serviceAccountUser"
Replace PRINCIPAL with the principal you are adding the binding for,
using in the form user|group|serviceAccount:email
or domain: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 developer needing these permissions, the Cloud Run service agent needs to be able to access the deployed container, which is the case by default.
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.