Deploying to Cloud Run with a custom service account failed with iam.serviceaccounts.actAs error

Question

I have created a custom service account travisci-deployer@PROJECT_ID.iam.gserviceaccount.com on my project and gave it the Cloud Run Admin role:

gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
   --member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
   --role="roles/run.admin"

Then I set this service account as the identity for my gcloud commands:

gcloud auth activate-service-account --key-file=google-key.json

But when I ran gcloud beta run deploy command, I got an error about the "Compute Engine default service account" not having iam.serviceAccounts.actAs permission:

gcloud beta run deploy -q "${SERVICE_NAME}" \
  --image="${CONTAINER_IMAGE}" \
  --allow-unauthenticated

Deploying container to Cloud Run service [$APP_NAME] in project [$PROJECT_ID] region [us-central1]
Deploying...
Deployment failed
ERROR: (gcloud.beta.run.deploy) PERMISSION_DENIED: Permission 'iam.serviceaccounts.actAs'
denied on service account [email protected]

This seems weird to me (because I'm not using the GCE default service account identity, although it's used by Cloud Run app once the app is deployed).

So the [email protected] account is being used for the API call, and not my travisci-deployer@PROJECT_ID.iam.gserviceacount service account configured on gcloud?

How can I address this?

Answer 1

TLDR: Add Cloud Run Admin and Service Account User roles to your service account.

If we read the docs in detail for the IAM Reference page for Cloud Run which is found here, we find the following text:

A user needs the following permissions to deploy new Cloud Run services or revisions:

• run.services.create and run.services.update on the project level. Typically assigned through the roles/run.admin role. It can be changed in the project permissions admin page.
• iam.serviceAccounts.actAs for the Cloud Run runtime service account. By default, this is [email protected]. The permission is typically assigned through the roles/iam.serviceAccountUser role.

I think these extra steps explain the story as you see it.