Score:0

Who should be the owner of a group of service accounts on Google Cloud Platform?

mg flag

I have an app that requires a set of permissions to various resources on the Platform. I want to have several (say 2) service accounts for this app to separate production activity from dev.

Generally Google recommends to avoid creating groups of service accounts (SA). They say SA corresponds to an app, and app is usually unique. It is not really unique in my case, I assume.

So I thought of creating a group, anyways, and got confused with the ownership. If I'm creating the group, I'm automatically becoming a member of the group, so I'm gaining all the permissions. Since this group is for the app, I'd like to avoid giving myself permissions based on the apps we are running on the platform, this may escalate pretty quickly.

Are there any conventional ways of solving this, or maybe I'm going the wrong direction? I didn't find any relevant discussion on the internet, so it very much may be the case :) Any advice is welcome!

Thank you!

Score:0
cn flag

Using groups is not required nor recommended.

The Owner account is a special project IAM member. You do not want to restrict the Owner account nor can you.

However, you should not be using the Owner account for normal usage. Only login with that identity when the privileges of that account are required.

As Owner you already have the permissions of any group or service account you create (except for Organizations where Owner is a lesser role). Use the principles of least privilege and create service accounts with only the required roles for each app.

Attach the service account to the service (Compute Engine, Cloud Run, Functions, etc.) and do not distribute keys to users or apps. Correctly written apps will use ADC (Application Default Credentials) to obtain credentials from the metadata service.

vindex10 avatar
mg flag
Thank you @JohnHanley, I might introduced some confusion by using the word Owner I didn't mean Owner account. I just meant "owner of the group", i.e. the one who created it, becomes a member automatically, thus gains the permissions not intended for them. I corrected the main question.
John Hanley avatar
cn flag
@vindex10 - Do not use groups. Read the last two paragraphs of my answer.
vindex10 avatar
mg flag
how would you suggest to test the app's new feature if it requires an additional permission? I'll need another SA anyways independently on how the app uses uses it.
John Hanley avatar
cn flag
@vindex10 - I don't understand your question. Why would an app need another permission? Assign the permissions the app requires to the service account. If you add a new feature that requires more permissions, add those permissions.
vindex10 avatar
mg flag
We have an app that reads a data from bucket A and is running in prod, now we are developing a new feature which would require a bucket B. We don't want to edit the SA of the app before the new feature is reviewed and merged. We, however, want to develop the feature and be able to test it on bucket B. As a result we need a service account that is "same as prod" + 1 more permission.
John Hanley avatar
cn flag
Production and developer apps can use different service accounts. Use the appropriate service account configured as required. There is no magic here. Assign the permissions required to the service accounts your require. Then deploy the correct service account to a system.
vindex10 avatar
mg flag
this is exactly why I need groups. I want to avoid copying permissions one by one, just adding a newly created service account to the group and add the extra permission. I'm glad we clarified it now :)
John Hanley avatar
cn flag
@vindex10 - Do as you wish, but assigning a permission to a group is no different than assigning a permission to a service account. Except you now have more objects to manage, more ways to break security and more access points. Review the [Principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege). Using groups breaks those guidelines.
John Hanley avatar
cn flag
@vindex10 - another point. Why do you want to use groups? If multiple service accounts are assigned to a group, then you do not those multiple service accounts. Use one service account instead of a group of service accounts. Creating artificial complexity is often the source of security breaches and systems failures.
vindex10 avatar
mg flag
second service account is temporary needed to test a new feature, before "new permissons" get assigned to the "primary" account. Having a group allows me to inherit a "production-like" permissions and do small changes on them, without changing production service account itself. It is not what I wish, I just dont see good alternative way which don't involve copying permissions of the prod account one by one.
John Hanley avatar
cn flag
@vindex10 - I have provided an answer to your question. If you reread the third paragraph of your question, you are arguing against your own question. Comments are for requesting information, not for chatting.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.