We discussed the Identity and Access Management bits of the GCP, and in that context, we observed that human identities are not actually defined in the GCP, rather they are seamlessly obtained from gsuite. Programmatic identities (service accounts) do in fact exist solely within the GCP though, as do roles.

Now, the reality of many organizations is that different teams manage the gsuite and GCP components. gsuite identities are often set up when a new employee joins the firm as a part of an onboarding process and might be organizationally linked to corporate IT, or even HR. GCP, on the other hand, is likely to be a core technology function that rolls up into the CTO.

This can have real practical implementations for how things get done. Say, for instance, that the GSuite team and the GCP teams don't get along well. Each time a new user joins or each time a user gets new responsibilities, that user might need to get added to the right gsuite groups (also known as Google groups). If the gsuite team is tardy getting this done, you as a cloud architect might find yourself taking little shortcuts like creating a service account that has whatever rights you want and then assigning those users the ServiceAccountActor role. This is a tempting shortcut, but one best avoided. You are almost certain to forget to revoke that ServiceAccountActor privilege once the Google group gets set up correctly and then years later that employee might go rogue and do bad things without any possibility of being traced because the ServiceAccountActor role makes those actions seem like a service account carried them out.

So, be a good corporate realist and make friends with the gsuite folks. You will need them a lot more than they will need you.