Is service account impersonation in GCP the best way to handle developer credentials and permissions?

1
votes

In GCP, service account impersonation is a way to create temporary IAM credentials to perform an action as developer (see here). This has been described as equivalent to assuming a role in AWS - see this other question.

My question is:

  • is this the recommended/canonical way of doing this in google cloud, namely grouping permissions around service accounts & allowing developers to inpersonate that service account ?
  • Or alternatively is it better to create custom roles and assign them directly to developers identities (and not indirectly via a service account)? But then of course you lose the advantage of short living credentials.

If the first option is valid, it would also mean that you would end up having as many service accounts as roles in AWS.

1
google-cloud-platformgoogle-iam
Seth Vargo's answer is correct. To add, it depends on what you are trying to accomplish and by what method. Security and Identity in Google Cloud is very different than AWS. It is best not to try to emulate one security design with another design. For users interacting with Google Cloud using the Console and Google CLI use User Credentials. For software programs use a service account. Impersonation is rarely used in Google Cloud and adds an unnecessary complication. In summary, use unique identities for authorization tailored for the tasks to be performed. – John Hanley

1 Answers

2
votes

In general, you should grant IAM roles to groups, and then add developers to the appropriate groups.

For example, you may want to grant all developers "Editor" access to a project. To do this, grant group:[email protected] the Editor role to the project. Then, use LDAP or G Suite to ensure that all developers are a member of that group.

You can give developers the ability to actAs a service account, but then the audit logs and principal would be the service account, not the developer.