CODEWITHSUNDEEP
google-cloud-platformpermissionsrolesgoogle-iamgoogle-cloud-iam
Sean Goldfarb
Sean Goldfarb

Reputation: 400

Understanding GCP IAM between multiple projects

In my organization, we work with GCP and have multiple projects there. I'm now trying to organize the IAM roles between all the projects and I'm not sure about some of the IAM settings. Are to projects act as completely separate entities with completely different IAM roles/permissions or are there any overlap between them that can lead to that a change in one project might affect another project?

Upvotes: 2

Views: 5072

Answers (2)

Jose Luis Delgadillo
Jose Luis Delgadillo

Reputation: 2448

The IAM roles you set in a project won't affect other projects.

Google Cloud resources are organized hierarchically, where the organization node is the root node in the hierarchy, the projects are the children of the organization, and the other resources are descendants of projects. You can set Identity and Access Management (IAM) policies at different levels of the resource hierarchy. Resources inherit the policies of the parent resource. The effective policy for a resource is the union of the policy set at that resource and the policy inherited from its parent.

Please check the following documentation where you will find a good explanation of the resource hierarchy for access control

I think this diagram can help you to understand better how IAM works: enter image description here

Upvotes: 1

Jen Person
Jen Person

Reputation: 7546

Changing roles in one project will not directly change roles set on another project. But there are some things you'll want to consider.

While projects can have their own access control rules, it is possible to manage access at more than the project level. Here are the four resource points where you can manage access:

Organization level. The organization resource represents your company. IAM roles granted at this level are inherited by all resources under the organization.

Folder level. Folders can contain projects, other folders, or a combination of both. Roles granted at the highest folder level will be inherited by projects or other folders that are contained in that parent folder.

Project level. Projects represent a trust boundary within your company. Services within the same project have a default level of trust. For example, App Engine instances can access Cloud Storage buckets within the same project. IAM roles granted at the project level are inherited by resources within that project.

Resource level. In addition to the existing Cloud Storage and BigQuery ACL systems, additional resources such as Genomics Datasets, Pub/Sub topics, and Compute Engine instances support lower-level roles so that you can grant certain users permission to a single resource within a project.

Access can be at the individual level, through a service account, or through organization-wide and Google Group membership. That means that when you add or remove someone from the organization or a Google group, you may inadvertently add or remove them from various roles in different projects.

Also, if a member (individual or group) is assigned a role that gives the capability to change IAM roles, then anyone in that member group can modify permissions. They may change rules in ways you don't want.

When in doubt, use testPermissions to verify that roles are working as expected.

Upvotes: 5

Related Questions