问题描述
在我的组织中，我们与GCP合作，并且在那里有多个项目。我现在正在尝试在所有项目之间组织IAM角色，但不确定某些IAM设置。是将项目充当具有完全不同的IAM角色/权限的完全独立的实体，还是它们之间是否存在重叠，从而导致一个项目的更改可能影响另一个项目？
解决方法
在一个项目中更改角色不会直接更改在另一个项目中设置的角色。但是，您需要考虑一些事项。
尽管项目可以拥有自己的访问控制规则，但可以在项目级别之外的其他地方manage access。以下是您可以管理访问权限的四个资源点：
组织级别。组织资源代表您的公司。 在此级别授予的IAM角色被所有资源继承。 组织。
文件夹级别。文件夹可以包含项目， 其他文件夹，或两者结合。最高职位 文件夹级别将被项目或其他文件夹继承 包含在该父文件夹中。
项目级别。项目代表 公司内部的信任边界。同一项目中的服务 具有默认的信任级别。例如，App Engine实例可以 访问同一项目中的Cloud Storage存储桶。 IAM角色 在项目级别授予的权限是由该范围内的资源继承的 项目。
资源级别。除了现有的Cloud Storage和 BigQuery ACL系统，其他资源，例如基因组数据集， 发布/订阅主题和Compute Engine实例支持较低级别的角色 这样就可以授予某些用户对单个资源的权限 在一个项目中。
访问权限可以是个人级别的，可以通过服务帐户，也可以是整个组织范围内和Google网上论坛的成员资格。这意味着，当您在组织或Google网上论坛中添加或删除某人时，可能会无意中将他们从不同项目中的各种角色中添加或删除。
此外，如果为成员（个人或组）分配了可以更改IAM角色的角色，则该成员组中的任何人都可以修改权限。他们可能会以您不希望的方式更改规则。
如有疑问，请使用testPermissions验证角色是否按预期工作。
您在项目中设置的IAM角色不会影响其他项目。
Google Cloud资源是按层次结构组织的，其中组织节点是层次结构中的根节点，项目是组织的子级，其他资源是项目的后代。您可以在资源层次结构的不同级别上设置身份和访问管理（IAM）策略。资源继承父资源的策略。资源的有效策略是该资源上设置的策略与从其父代继承的策略的并集。
请检查以下documentation，您将在其中找到有关访问控制的资源层次的很好解释
我认为此图可以帮助您更好地了解IAM的工作原理：
