Roles set on one project cannot be easily changed on another project. You need to take a few factors into account, though.
While individual projects may have their own access control policies, access can also be managed at levels above and beyond projects. The four resource locations where you can control access are as follows:
- a company's level. The organizational resource speaks for your business. All resources inside the organization inherit any IAM roles provided at this level.
- the folder level. Projects, other folders, or a combination of both can be found in folders. Projects or other folders included within the parent folder will inherit any roles provided at the top folder level.
- Project scale. Within your business, a trust boundary is represented by projects. Services that are part of the same project are assumed to be trustworthy. For instance, Cloud Storage buckets located inside the same project can be accessed by App Engine instances. Resources within a project inherit IAM roles that have been granted at the project level.
- level of resources. Genomics Datasets, Pub/Sub topics, and Compute Engine instances are additional resources that enable lower-level roles in addition to the current Cloud Storage and BigQuery ACL systems, allowing you to grant certain users access to a single resource inside a project.
- Individual access, access through a service account, organization-wide access, and membership in Google Groups are all options. This means that you could unintentionally add or remove someone from numerous roles in various projects when you add or delete them from the organization or a Google group.
- Additionally, anyone in that member group can alter permissions if they have been allocated a role that allows them to change IAM roles. They might alter the regulations in a way that you don't want
