We have a number of situations where a person running one of our applications needs it to access a variety of different resources - different GCS buckets, a couple of cloud functions, and so on. For access, we can create a Google Group on the Workspace side of our universe, and give that group access to each of the resources via IAM. That way, we only have to manage the set of people in one place, rather than having to add or remove each person from each IAM policy. So far so good.
Now, via workload identity federation, we have machine principals that should also be able to run these applications (example: lab workstations that should be able to automatically upoload experiment results and trigger their processing). However, managing the access of these principals is not as easy - Google Groups can’t contain non-email-address principals (like principal:// from workload identity, see Principal identifiers | IAM Documentation | Google Cloud ).
Are there good ways to manage this? I’m contemplating using service account impersonation for each machine principal and putting the service accounts email addresses in the workspace Group, but that adds an additional layer and management of the group membership is different from managing anything GCP-side - for example, group membership is controlled by admin priveleges on the Workspace side, not by IAM, so it would be hard to automate with the IAM roles of our CI system. The other option that’s come to mind is adding some machinery to our IAM management (in Terraform) to do group expansion on “our side”.
Is there really no built-in IAM abstraction for assigning a role and resource to a group of principals?