Adding roles to service accounts on Google Cloud Platform using REST API

Question

I want to create a service account on GCP using a python script calling the REST API and then give it specific roles - ideally some of these, such as roles/logging.logWriter.

First I make a request to create the account which works fine and I can see the account in Console/IAM.
Second I want to give it the role and this seems like the right method. However, it is not accepting roles/logging.logWriter, saying HttpError 400, "Role roles/logging.logWriter is not supported for this resource.">
Conversely, if I set the desired policy in console, then try the getIamPolicy method (using the gcloud tool), all I get back is response etag: ACAB, no mention of the actual role I set. Hence I think these roles refer to different things.

Any idea how to go about scripting a role/scope for a service account using the API?

Cribriform

Quick note: If you don't have some sort of global roles, usually, set the roles for the thing ("principal")(service account here) in the permissions of the target (e.g. in Edit access of a bucket) - don't get confused - the service account itself has permissions section but those are permission to "manage/view" the service account itself, not service account's permissions to other stuff :-) – Berberidaceous

Answer 1

You can grant permissions to a GCP service account in a GCP project without having to rewrite the entire project policy!

Use the gcloud projects add-iam-policy-binding ... command for that (docs).

For example, given the environment variables GCP_PROJECT_ID and GCP_SVC_ACC the following command grants all privileges in the container.admin role to the chosen service account:

gcloud projects add-iam-policy-binding ${GCP_PROJECT_ID} \
    --member=serviceAccount:${GCP_SVC_ACC} \
    --role=roles/container.admin

To review what you've done:

$ gcloud projects get-iam-policy $GCP_PROJECT_ID \
    --flatten="bindings[].members" \
    --format='table(bindings.role)' \
    --filter="bindings.members:${GCP_SVC_ACC}"

Output:

ROLE
roles/container.admin

(or more roles, if those were granted before)

Notes:

• The environment variable GCP_SVC_ACC is expected to contain the email notation for the service account.
• Kudos to this answer for the nicely formatted readout.

Ghyll

Looks like there is a missing trailing backslash in the first gcloud projects command example on line 2. – Foreshow

Thank you, Jeff! Looks like I fixed that but forgot to say thank you. – Ghyll

Answer 2

You appear to be trying to set a role on the service account (as a resource). That's for setting who can use the service account.

If you want to give the service account (as an identity) a particular role on the project and its resources, see this method: https://cloud.google.com/resource-manager/reference/rest/v1/projects/setIamPolicy

Michelsen

one should be extremely careful, the page starts with the following : Sets the IAM access control policy for the specified Project. Overwrites any existing policy. – Stoss

Yes, get the existing policy first, modify it, then write it. – Michelsen

still wouldn't it be advisable to set serviceAccounts that would receive other serviceAccounts/users (the first sentence of your answer) ? this full overwrites feels extreme, a mistake can screw your whole project. To be honest, I'm finding it hard to understand those two correctly on gcloud; compared let's say to aws, where groups/users are more understandable. Feels safer, you can toggle a user from a group. May I ask you if a comparable pattern exists on gcloud ? – Stoss

@ben were you able to do it in a safer way? – Lithuanian

Nope; gave up and went further on aws – Stoss

// , I got the same error when trying to GET the associated role. I run into this BS any time I try to use GCP without Terraform. gcloud has a looooot of little gotchas. – Pepsin

// , ACAB is some real trash as far as UX. If GCP were actually popular I'd nominate it as this generation of DevOps' PC Load Letter youtube.com/watch?v=Mw-8oEO8bZo – Pepsin

Using projects add-iam-policy-binding seems to be a less risky, more viable, easier to use solution to the given problem. I have added a new answer, please review! – Ghyll

Answer 3

If you wanted to do it to multiple:

PROJECTS=$(gcloud projects list --format="value(projectId)")

for PROJECT in $PROJECTS; do
    gcloud projects add-iam-policy-binding ${PROJECT} \
        --member=serviceAccount:terraform@$PROJECT.iam.gserviceaccount.com \
        --role=roles/iam.serviceAccountAdmin
done

Caffey