Rather than think of giving a user/service account permissions "globally", think about giving those permissions contextually. Imagine a user with the identity of [email protected]
. You want that user to be able to create projects ... but it isn't as simple as that. Within GCP, you have the concept of folders which can contain projects. If I have two folders folder1
and folder2
, and I want to the user to be able to create projects in folder1
but not folder2
, we seem to have a problem. If I said that the user could just create projects, that would be too broad.
The better way to think about it is that there is a hierarchy of resources ... these start at the root (the organization) and then we have folders beneath that (optionally) and we end up with projects. Now we have enough to complete the story.
What GCP allows us to do is state:
At this level (organization or folder) I wish to give this user this permission. This then propagates downwards from that tree level but does not propagate horizontally.
And thus we get to the root of your question. When you go to IAM, you are trying to associate roles to a user "globally" as opposed to "contextually". There is no concept of giving a user project create globally ... instead you give it contextually either at an organization or folder level. Note that if you assign a permission at the organization level, that is effectively global as everything nests down from the organization.
assigned
orinherited
at the level which will be the parent of any new projects" – Nnw