0

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!

Community
  • 1
vindex10
  • 1
  • 1

1 Answers1

0

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.

John Hanley
  • 4,754
  • 1
  • 11
  • 21
  • 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. – vindex10 Aug 04 '23 at 19:03
  • @vindex10 - Do not use groups. Read the last two paragraphs of my answer. – John Hanley Aug 04 '23 at 20:46
  • 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. – vindex10 Aug 05 '23 at 10:50
  • @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. – John Hanley Aug 05 '23 at 12:55
  • 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. – vindex10 Aug 05 '23 at 13:11
  • 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. – John Hanley Aug 05 '23 at 13:14
  • 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 :) – vindex10 Aug 05 '23 at 15:02
  • @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 Aug 05 '23 at 16:43
  • @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. – John Hanley Aug 05 '23 at 16:51
  • 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. – vindex10 Aug 06 '23 at 12:45
  • @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. – John Hanley Aug 06 '23 at 12:47