How do you enable "iam.serviceAccounts.actAs" permissions on a sevice account?

Question

I am trying to deploy a service with a non-default service account by following this guide and it says I need "the iam.serviceAccounts.actAs permission on the service account being deployed". The service account I am using is @cloudbuild.gserviceaccount.com, but I don't see the option to add it on my project's Permissions page.

Sceptic

Answer 1

The key point is that the service account is a resource. You need to add an IAM role for your identity to the service account (the resource). This grants you permissions on the resource (service account).

• Open the Google Cloud Console. Go to IAM & Admin -> Service accounts.

• Find the service account. Tick the box to the left of the service account.

• In the right-hand "Permissions" panel, click ADD MEMBER

• Add your IAM member email address. For the role select Service Accounts -> Service Account User.

• Click Save

You can also you the CLI:

gcloud iam service-accounts add-iam-policy-binding [SERVICE_ACCOUNT] --member [MEMBER_EMAIL] --role roles/iam.serviceAccountUser

gcloud iam service-accounts add-iam-policy-binding

Flores

For Cloud Run specifically, I need to add permissions to [PROJECT_NUMBER][email protected] (according to this guide) and I don't see that on the Service accounts page, but I do see it on the IAM page. I have already added a Secret Manager Admin role to my cloud build service account, but my deployed container cannot access the Secret Manager – Sceptic

That service account is the "Compute Engine default service account". It has to be there under "Service accounts". This is created by Google for you. Go back and look again. If you deleted it, contact Google support. The entry under "IAM" is for the project (granting permissions to the service account to resources in the project) and not for the service account resource. cloud.google.com/compute/docs/access/… – Flores

for some reason, the CLI command in the answer fails from my Ubuntu. This works: gcloud iam service-accounts add-iam-policy-binding [email protected] --member='user:[email protected]' --role='roles/iam.serviceAccountUser' Note the extra "=user:" thing. – Eclat

@Eclat - Your comment is correct. For users, prepend the email address with user:, for service accounts prepend with serviceAccount:, etc. There are additional types such as group, domain, etc. This is documented in the link in my answer. – Flores

UI apparently has changed, because even as an Org Admin I cannot find "Permissions" panel and "Add member". I can see "Manage permissions" but it redirects me pretty much to the main page with "Permissions". – Skippie

@GregWozniak - In the Permissions tab, look for GRANT ACCESS (left side above the list of principals and below VIEW BY PRINCIPALS). Remember this screen modifies the service account's IAM policy, which is not the same as a project's IAM policy. – Flores

Answer 2

On the service account you are using, you need to give yourself the role of Service Account User.

Go to IAM -> Service Accounts -> (Your service Account) -> Permissions -> Grant Access

(By doing this you are granting yourself access to use this service account)

See also:

• Unable to create a new Cloud Function - cloud-client-api-gae
• Cloud Build fails to deploy to Google App Engine - You do not have permission to act as @appspot.gserviceaccount.com

Desantis

Answer 3

TL;DR: Add Service Account User role to the service account that you're doing your deployment as. This is at least valid in my use case: gcloud run deploy <SERVICE>

Long answer: Left aside that I totally disagree with the current answer starting with

The key point is that the service account is a resource, as the resource, in my case, is a Cloud Run service, and not an SA, and modulo the shortcoming of GCP's IAM console search engine's ability to search for technical names such as iam.serviceAccounts.actAs, but rather English names, such as Service Account User, the idea is that the SA that you've authenticated as to do your deployment may need to act as the compute engine's user, or any other service's user, to perform some tasks, hence the requirement to impersonate that account.

We'll note that if you quickly type in "service accounts" in the free search text of IAM Role for your SA, the pertinent target will not come up, because of the plural form... This is a shame, as there are just too few clues to find out that Service Account User is the English that resolves for iam.serviceAccounts.actAs.

We'll also note that typing in "act as", or "impersonate" leads to nothing, since the privilege descriptions are not indexed by the search engine...

Correa