本页面介绍了 Trusted Cloud by S3NS的 Identity and Access Management (IAM) 系统的工作原理以及如何使用它在 Trusted Cloud中管理访问权限。
IAM 是一种工具，用于管理Trusted Cloud的精细授权。换言之，您可以用它控制谁可以对哪些资源执行何种操作。
Trusted Cloud中的访问权限
Trusted Cloud 中的每个操作都需要特定的权限。当有人尝试在 Trusted Cloud中执行操作时（例如创建虚拟机实例或查看数据集），IAM 会先检查他们是否拥有所需的权限。如果没有，IAM 会阻止他们执行操作。
在 IAM 中向某人授予权限涉及以下三个部分：
- 主账号：您要授予权限的人员或系统的身份
- 角色：您要向主账号授予的权限集合
- 资源：您要让主账号访问的 Trusted Cloud 资源
如需向主账号授予访问资源的权限，您可以向其授予资源的角色。您可以使用允许政策授予这些角色。
下面几个部分将详细介绍这些概念。
主账号
在 Trusted Cloud 中，您可以控制主账号的访问权限。主账号代表已向 Trusted Cloud进行身份验证的一个或多个身份。
过去，主账号称为成员。部分 API 仍在使用该术语。
IAM 中有各种类型的主账号，但这些主账号可以分为两大类：
真人用户：某些 IAM 主账号类型代表真人用户。您可以使用这些主账号类型来管理员工对Trusted Cloud 资源的访问权限。
例如，员工身份池中的联合身份代表的是真人用户。
工作负载：某些 IAM 主账号类型代表工作负载。在管理工作负载对Trusted Cloud 资源的访问权限时，您需要使用这些主账号类型。
代表工作负载的主账号类型包括工作负载身份池中的服务账号和联合身份。
如需详细了解主账号，请参阅 IAM 主账号。
权限和角色
权限决定了可以对资源执行的操作。在 IAM 中，权限通常以 service.resource.verb 形式表示。权限通常与 REST API 方法一一对应，例如，resourcemanager.projects.list 权限可让您列出 Resource Manager 项目。
您不能直接向主账号授予权限。但您可以通过向主账号授予角色来授予权限。
角色是各种权限的集合。当您向主账号授予角色时，您将向该主账号授予该角色中的所有权限。
角色分为三种类型：
预定义角色：由 Trusted Cloud 服务管理的角色。这些角色包含为每项指定服务执行常见任务所需的权限。例如，Pub/Sub Publisher 角色 (
roles/pubsub.publisher) 提供将消息发布到 Pub/Sub 主题的访问权限。自定义角色：您创建的角色，其中仅包含您指定的权限。您可以完全控制这些角色中的权限。 不过，与预定义角色相比，自定义角色的维护负担更高，并且您在项目和组织中可以拥有的自定义角色数量是有限制的。
基本角色：容许程度较高的角色，可提供对Trusted Cloud 服务的广泛访问权限。这些角色适用于测试用途，但不应在生产环境中使用。
如需详细了解角色和权限，请参阅角色和权限。
资源
大多数 Trusted Cloud 服务都有自己的资源。例如，Compute Engine 具有实例、磁盘和子网等资源。
在 IAM 中，您可以授予针对某个资源的角色。向主账号授予针对某个资源的角色意味着，该主账号可以使用该角色中的权限来访问相应资源。
您可以授予针对部分 Trusted Cloud 资源的角色。如需查看您可以授予角色的资源的完整列表，请参阅接受允许政策的资源类型。
Trusted Cloud 还有多个容器资源，其中包括项目、文件夹和组织。向主账号授予容器资源的角色后，主账号便可访问容器资源和该容器中的资源。借助此功能，您可以使用单个角色授予向主账号授予对多个资源的访问权限，包括您无法直接授予角色的资源。如需了解详情，请参阅本页面上的政策继承。
允许政策
您可以使用允许政策向主账号授予角色。过去，这些政策称为 IAM 政策。
允许政策是附加到 Trusted Cloud资源的 YAML 或 JSON 对象。
每个允许政策都包含一组角色绑定，这些角色绑定会将 IAM 角色与已被授予这些角色的主账号相关联。
当经过身份验证的主账号尝试访问资源时，IAM 会检查该资源的允许政策，以确定主账号是否具有所需权限。如果主账号参与了角色绑定，且该角色绑定包含具有所需权限的角色，则主账号有权访问相应资源。
如需查看允许政策示例并了解其结构，请参阅了解允许政策。
政策继承
Trusted Cloud 包含容器资源（例如项目、文件夹和组织），可让您按父级/子级层次结构整理资源。此层次结构称为资源层次结构。
Trusted Cloud 资源层次结构具有以下结构：
- 组织是层次结构中的根节点。
- 文件夹是组织或其他文件夹的子项。
- 项目是组织或文件夹的子项。
- 每个服务的资源都是项目的后代。
下图为 Trusted Cloud 资源层次结构的示例：
如果您对容器资源设置了允许政策，则该允许政策也会应用于该容器中的所有资源。此概念称为“政策继承”，因为后代资源会有效地继承其祖先资源的允许政策。
政策继承具有以下可能的影响：
您可以使用单个角色绑定来授予对多个资源的访问权限。如果您想向主账号授予对容器中所有资源的访问权限，请向其授予针对容器的角色，而不是针对容器中资源的角色。
例如，如果您想让安全管理员管理贵组织中所有资源的许可政策，则可以向其授予该组织的 Security Admin 角色 (
roles/iam.securityAdmin)。您可以授权访问没有自己的允许政策的资源。并非所有资源都接受允许政策，但所有资源都会从其祖先继承允许政策。如需授权主账号访问无法拥有自己的允许政策的资源，请向其授予某个资源祖先的角色。
例如，假设您想授予某人将日志写入日志存储桶的权限。日志存储桶没有自己的允许政策，因此如需向某人授予此权限，您可以改为向其授予包含日志存储桶的项目的 Logs Bucket Writer 角色 (
roles/logging.bucketWriter)。若要了解谁可以访问资源，您还需要查看影响资源的所有允许政策。如需获取对资源具有访问权限的主账号的完整列表，您需要查看资源的允许政策和资源祖先的允许政策。所有这些政策的并集称为有效允许政策。
如需详细了解允许政策的政策继承，请参阅使用资源层次结构实现访问权限控制。
高级访问权限控制
除了允许政策之外，IAM 还提供了以下访问权限控制机制来帮助您细化哪些人有权访问哪些资源：
- 拒绝政策：即使主账号被授予包含特定权限的角色，拒绝政策也会阻止主账号使用该权限。如需详细了解拒绝政策，请参阅拒绝政策。
IAM Conditions：IAM Conditions 可让您定义和强制执行有条件、基于属性的访问权限控制。您可以在各种政策类型中使用条件。例如，您可以向允许政策中的角色绑定添加条件，以确保仅在满足条件时才授予角色。
您可以根据请求中的资源和请求时间等属性来编写条件。
如需详细了解 IAM Conditions，请参阅 IAM Conditions 概览。
IAM API 的一致性模型
IAM API 提供最终一致性。换句话说，如果您使用 IAM API 写入数据，然后立即读取该数据，则读取操作可能会返回旧版数据。此外，您进行的更改可能需要一段时间才能影响访问权限检查。
这种一致性模型会影响 IAM API 的工作方式。例如，如果您创建了一个服务账号，然后在另一个请求中立即引用该服务账号，则 IAM API 可能会提示找不到该服务账号。出现这种行为的原因是操作是最终一致的；新服务账号可能需要一段时间才能供读取请求使用。
后续步骤
- 如需了解如何为 Trusted Cloud配置身份，请参阅适用于 Trusted Cloud的身份管理。
- 如需了解如何对主账号授予、更改和撤消 IAM 角色的说明，请参阅管理对项目、文件夹和组织的访问权限。
- 如需查看可用 IAM 角色的列表，请参阅预定义角色。
- 如需获取有关选择最合适的预定义角色的帮助，请参阅查找合适的预定义角色。
- 如需详细了解 IAM 中可用的政策类型，请参阅政策类型。