Should Service Accounts be Allowed as Members of Google Groups? | C2C Community

Should Service Accounts be Allowed as Members of Google Groups?

  • 30 June 2021
  • 9 replies

Hi everyone,


This question came up for me this morning with our Security Operations team. The context is GCP, but Groups transcend Workspace so I came over here to ask for opinions as well.

SecOps gave me an example of an existing group with a bunch of service account members. When I inspected the GCP role assignments of these members I noticed they were almost the same; a couple service account had different roles. To me a group is a collection of things meant to be managed in the same way.

At a minimum, my view is that groups should be homogeneous: all user accounts or all service accounts. Moreover I can be easily convinced service accounts ought to be banned from groups altogether in a cloud application environment despite Google’s allowing it:

What’s your take?

9 replies

Userlevel 7
Badge +26

@tuliani as a Google employee with security experience, what is your take on this? @Kartik as a System Architect, what would you do in this situation?

Userlevel 2
Badge +1

Previously, you had to use domain-wide delegation and admin impersonation to provide service accounts with sufficient data access. This was a cumbersome process, which could result in overly broad privileges for the service account and audit logs that were hard to interpret. 


However, Service accounts can now have direct access to Groups APIs without needing domain-wide delegation and admin impersonation. This means you can: 

  • Assign an admin role to a service account using the Admin SDK roles API and Admin console Roles page
  • Use a service account with an admin role to manage groups at a customer level via the Admin SDK Groups API and the Cloud Identity Groups API
  • Use a service account with group owner or manager role (non-admin) to manage groups via the Cloud Identity Groups API. 
  • See accurate audit logs with service accounts as the actor. 

    Hope it helps.
Userlevel 4
Badge +6

The answer is somewhere between yes and no. 

Yes they should be part if you exclusively use groups to manage access to GCP. Thus service accounts that need access to GCP resources need to be part of groups.

No they should not be in distribution lists or other non-targeted groups. 

@Goldyarora Thanks for your response. Those use cases are not really what I am facing. My concern is exclusively regarding GCP itself. As I see it service accounts aren’t people. As such there’s an argument that they shouldn’t be mixed with people in groups when we’re talking about access control. As an example, user accounts have a need to have the Owner role on occasion. There is never a time when I’d assign Owner to a service account. Hence, to put a service account in a group with users is to risk that account inheriting inappropriate roles from its group assignment. I see this as unacceptable risk.

@dominikkugelmann do you manage access to GCP exclusively using groups or know anyone who does? I find that hard to imagine. 

Userlevel 4
Badge +6

@mrichter almost exclusively. If I need to assign some specific role to some specific one time service account, often not. But user access is basically always managed through groups.  

Userlevel 2
Badge +1

@mrichter - It really depends on the use case.

As you said, service accounts are usually used for machine to machine interactions, think of them as a robot in your kitchen which can assist you in getting a few things done.

Now whether you need them as a part of your family (or group) really depends on your requirements.

An example of such requirement may be, you offer a training service which can be accessed by anyone who is part of your "subscribers" group, now you have another portal where your customers purchase your services, to give them automated access, you may leverage service account which can programmatically manage your "subscribers" group instead of asking a owner/manager of that group to do it manually.

Of course, I would start with no service account in the group, only add them if required, and also follow best practices such as regular auditing to ensure least Priveleges.

I would also recommend labeling your groups for easy classification

I personally do not like having service accounts in groups at all. I understand why Google opened up the capability, but it’s dangerous.

Userlevel 2
Badge +1

I won't comment on your liking/disliking, but service accounts can NOT do something by themselves unless you have intentionally made a program which leverages them in some way.


Of course! My original question had to do with the hygiene of whether they ought to be members of groups.