What predefined IAM roles does a service account need to complete the Google Cloud Run Quickstart: Build and Deploy?

Question

I want to compare Google Cloud Run to both Google App Engine and Google Cloud Functions. The Cloud Run Quickstart: Build and Deploy seems like a good starting point.

My Application Default Credentials are too broad to use during development. I'd like to use a service account, but I struggle to configure one that can complete the quickstart without error.

The question:

What is the least privileged set of predefined roles I can assign to a service account that must execute these commands without errors:

gcloud builds submit --tag gcr.io/{PROJECT-ID}/helloworld
gcloud beta run deploy --image gcr.io/{PROJECT-ID}/helloworld

The first command fails with a (seemingly spurious) error when run via a service account with two roles: Cloud Build Service Account and Cloud Run Admin. I haven't run the second command.

Edit: the error is not spurious. The command builds the image and copies it to the project's container registry, then fails to print the build log to the console (insufficient permissions).

Edit: I ran the second command. It fails with Permission 'iam.serviceaccounts.actAs' denied on {service-account}. I could resolve this by assigning the Service Account User role. But that allows the deploy command to act as the project's runtime service account, which has the Editor role by default. Creating a service account with (effectively) both Viewer and Editor roles isn't much better than using my Application Default Credentials.

So I should change the runtime service account permissions. The Cloud Run Service Identity docs have this to say about least privileged access configuration:

This changes the permissions for all services in a project, as well as Compute Engine and Google Kubernetes Engine instances. Therefore, the minimum set of permissions must contain the permissions required for Cloud Run, Compute Engine, and Google Kubernetes Engine in a project.

Unfortunately, the docs don't say what those permissions are or which set of predefined roles covers them.

What I've done so far:

1. Use the dev console to create a new GCP project
2. Use the dev console to create a new service account with the Cloud Run Admin role
3. Use the dev console to create (and download) a key for the service account
4. Create (and activate) a gcloud configuration for the project

$ gcloud config list
[core]
account = {service-account-name}@{project-id}.iam.gserviceaccount.com
disable_usage_reporting = True
project = {project-id}
[run]
region = us-central1

5. Activate the service account using the downloaded key
6. Use the dev console to enable the Cloud Run API
7. Use the dev console to enable Container Registry→Settings→Container Analysis API
8. Create a sample application and Dockerfile as instructed by the quickstart documentation
9. Run gcloud builds submit --tag gcr.io/[PROJECT-ID]/helloworld
   ...fails due to missing cloud build permissions
10. Add the Cloud Build Editor role to service account and resubmit build
    ...fails due to missing storage permissions. I didn't pay careful attention to what was missing.
11. Add the Storage Object Admin role to service account and resubmit build
    ...fails due to missing storage bucket permissions
12. Replace service account's Storage Object Admin role with the Storage Admin role and resubmit build
    ...fails with

Error: (gcloud.builds.submit) HTTPError 403:
<?xml version='1.0' encoding='UTF-8'?>
<Error>
<Code>AccessDenied</Code>
<Message>Access denied.</Message>
<Details>
{service-account-name} does not have storage.objects.get access to
{number}.cloudbuild-logs.googleusercontent.com/log-{uuid}.txt.</Details>
</Error>

13. Examine the set of available roles and the project's automatically created service accounts. Realize that the Cloud Build Service Account role has many more permissions that the Cloud Build Editor. This surprised me; the legacy Editor role has "Edit access to all resources".
14. Remove the Cloud Build Editor and Storage Admin roles from service account
15. Add the Cloud Build Service Account role to service account and resubmit build
    ...fails with the same HTTP 403 error (missing get access for a log file)
16. Check Cloud Build→History in the dev console; find successful builds!
17. Check Container Registry→Images in the dev console; find images!

At this point I think I could finish Google Cloud Run Quickstart: Build and Deploy. But I don't want to proceed with (seemingly spurious) error messages in my build process.

Answer 1

Cloud Run PM here:

We can break this down into the two sets of permissions needed:

# build a container image
gcloud builds submit --tag gcr.io/{PROJECT_ID}/helloworld

You'll need:

1. Cloud Build Editor and Cloud Build Viewer (as per @wlhee)

# deploy a container image
gcloud beta run deploy --image gcr.io/{PROJECT_ID}/helloworld

You need to do two things:

1. Grant your service account the Cloud Run Deployer role (if you want to change the IAM policy, say to deploy the service publicly, you'll need Cloud Run Admin).
2. Follow the Additional Deployment Instructions to grant that service account the ability to deploy your service account

#1
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:{service-account-name}@{project-id}.iam.gserviceaccount.com" \
  --role="roles/run.developer"

#2
gcloud iam service-accounts add-iam-policy-binding \
  [email protected] \
  --member="serviceAccount:{service-account-name}@{project-id}.iam.gserviceaccount.com" \
  --role="roles/iam.serviceAccountUser"

EDIT: As noted, the latter grants your service account the ability to actAs the runtime service account. What role this service account has is dependent on what it needs to access: if the only thing Run/GKE/GCE accesses is GCS, then give it something like Storage Object Viewer instead of Editor. We are also working on per-service identities, so you can create a service account and "override" the default with something that has least-privilege.