Search code examples
google-cloud-platformpermissionsrolesgoogle-iamgoogle-cloud-iam

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?


Solution

  • 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.