在我的组织中，我们与 GCP 合作并在那里有多个项目。我现在正在尝试组织所有项目之间的 IAM 角色，但我不确定某些 IAM 设置。项目是否作为具有完全不同 IAM 角色/权限的完全独立的实体，或者它们之间是否存在任何重叠，从而导致一个项目的更改可能会影响另一个项目？
【问题讨论】：
标签： google-cloud-platform permissions roles google-iam google-cloud-iam
在一个项目中更改角色不会直接更改在另一个项目中设置的角色。但有些事情你需要考虑。
虽然项目可以有自己的访问控制规则，但manage access 可以在项目级别以上。以下是您可以管理访问权限的四个资源点：
组织层级。组织资源代表您的公司。 在此级别授予的 IAM 角色由以下所有资源继承 组织。
文件夹级别。文件夹可以包含项目， 其他文件夹，或两者的组合。最高授予的角色 文件夹级别将由项目或其他文件夹继承 包含在该父文件夹中。
项目级别。项目代表一个 公司内部的信任边界。同一项目内的服务 具有默认的信任级别。例如，App Engine 实例可以 访问同一项目中的 Cloud Storage 存储分区。 IAM 角色 在项目级别授予的资源由该项目级别内的资源继承 项目。
资源级别。除了现有的云存储和 BigQuery ACL 系统、基因组数据集等其他资源、 Pub/Sub 主题和 Compute Engine 实例支持较低级别的角色 这样您就可以授予某些用户对单个资源的权限 在一个项目中。
可以在个人级别、通过服务帐户或通过组织范围内的 Google 群组成员身份进行访问。这意味着，当您在组织或 Google 群组中添加或移除某人时，您可能会无意中将他们添加到不同项目的不同角色中或从中移除。
此外，如果为成员（个人或组）分配了能够更改 IAM 角色的角色，则该成员组中的任何人都可以修改权限。他们可能会以您不希望的方式更改规则。
如有疑问，请使用testPermissions 验证角色是否按预期工作。
【讨论】：
您在一个项目中设置的 IAM 角色不会影响其他项目。
Google Cloud 资源按层次结构组织，其中组织节点是层次结构中的根节点，项目是组织的子节点，其他资源是项目的后代。您可以在资源层次结构的不同级别设置身份和访问管理 (IAM) 策略。资源继承父资源的策略。资源的有效策略是在该资源上设置的策略与从其父级继承的策略的联合。
请查看以下documentation，您将在其中找到访问控制资源层次结构的详细说明
【讨论】：