借助 Google Distributed Cloud (GDC) air-gapped 中的 Identity and Access Management (IAM)，您可以控制谁有权访问哪些资源，以及他们可以在这些资源上执行哪些操作。
了解 IAM 在 GDC 中的运作方式有助于您有效地管理访问权限，确保成员拥有执行其角色所需的权限，同时维护 air-gapped 环境的安全性。
本文档面向平台管理员和应用操作员组（例如 IT 管理员、安全工程师或应用开发者）中的受众，他们希望了解 GDC 网闸隔离配置 中的授权和访问权限控制。本文档还有助于基础架构运维人员对访问权限控制概念建立基础了解。如需了解详情，请参阅 GDC 网闸隔离配置文档的受众。
访问权限控制模型
GDC 围绕三个核心组件构建访问权限： 成员（谁）、 角色（什么）和 资源范围（哪里）。
访问权限控制包含两个不同的阶段：证明您的身份（身份验证）和确定您可以执行的操作（授权）：
- 身份验证： GDC 不存储用户账号或密码。GDC 会连接到您组织的身份提供方 (IdP)，以便您可以使用公司凭据登录。
- 授权： 身份验证后，GDC IAM 会检查您分配的角色，以确定您可以访问哪些资源以及可以执行哪些操作。
成员
成员是您可以向其授予资源访问权限的身份。 GDC 会根据您管理成员的位置将成员分为两个主要类别：人类身份和非人类身份。
人类身份
人类身份是指登录 GDC 的用户和群组。GDC 不会存储用户账号或密码，而是使用标准身份联合协议（例如 OpenID Connect (OIDC) 或 SAML 2.0）连接到您组织的现有登录系统或 IdP（例如 Active Directory、LDAP 或 Okta）。
人类身份有两种类型：
- 用户： 使用公司凭据登录系统的个人人类用户。
- 群组： 在您组织的 IdP 中管理的人类用户集合。向群组授予角色会自动向该群组的所有成员授予该角色。
GDC 使用 IdP 来唯一标识人类身份。 由于您的环境可以连接到多个 IdP（例如，如果不同的部门使用不同的登录系统），因此 GDC 会区分 IdP，以确保您向正确的人员授予访问权限。
在管理访问权限时，GDC 会自动为所有外部用户名和群组添加唯一的 IdP 前缀：
- 格式：
idpprefix-username@domain.com（对于群组，则为idpprefix-group-name）。 - 示例： 如果您组织的 IdP 配置了前 ix
agency-a，并且您以alice@example.com身份登录， 则 GDC IAM 会将您识别为agency-a-alice@example.com。
非人类身份
非人类身份称为服务身份（或服务账号）。您可以在 GDC 中直接创建和管理这些身份（作为 ProjectServiceAccount 资源），以便应用、脚本或自动化工作负载与 API 安全地交互。
由于服务账号由 GDC 在内部管理，因此它们不使用 IdP 前缀。相反，它们由其项目和名称标识（例如，使用 gdcloud CLI 时为 serviceAccount:projectName:serviceAccountName）。
如需了解详情，请参阅 服务帐号。
权限和角色
权限是指对资源执行特定操作的授权（例如，创建虚拟机或删除数据库）。您不能直接向成员授予权限。相反，GDC 会将权限捆绑到角色中。
GDC 提供两种类型的角色：
- 预定义角色： 由 GDC 创建和管理的内置权限捆绑包。GDC 提供了一个全面的预定义角色库，这些角色是根据特定的工作职能和服务量身定制的（从 Project Viewer 等广泛的角色到 Bucket Project Admin 或 KMS Viewer 等精细的服务角色）。
- 自定义角色： 用户定义的权限捆绑包，当现有预定义角色无法满足组织的需求时，您可以创建这些角色。
通过 IAM 角色授予的权限纯粹是附加权限；它们授予访问权限，但不包含拒绝规则。当您向成员授予多个角色时，该成员会获得这些角色中的所有权限的并集。如需 限制或拒绝组织中对特定服务的访问权限，您可以 设置组织政策。
资源范围
您始终在 GDC 资源层次结构的特定级别授予访问权限。范围决定了成员可以访问哪些资源。 在多可用区环境中，在任一范围分配的角色默认会自动应用于所有可用区。
您可以在以下资源范围内授予角色：
- 组织： 您的环境的顶级容器。在组织级别授予的角色适用于整个组织，会自动向下继承到其中的所有项目和资源。
- 项目： 组织内用于对特定团队或应用的资源进行分组的容器。项目充当严格的安全边界 - 在项目级别授予的角色仅适用于该特定项目及其资源（例如虚拟机、数据库和 Kubernetes 集群）。
如需了解详情，请参阅 资源层次结构和 多可用区环境的权限控制。
如何授权访问
GDC 主要使用基于角色的访问权限控制 (RBAC) 模型来管理和授权访问权限。在 RBAC 模型中，您不会直接向单个用户或工作负载分配权限。相反，您会在特定资源范围内向成员分配角色，以确定访问权限。
GDC 使用以下 Kubernetes 自定义资源实现 RBAC：
IAMRole：定义特定权限捆绑包。IAMRoleBinding：在组织或项目范围内将成员（人类用户、群组或服务帐号） 链接到IAMRole。
如需授予对组织或项目资源的访问权限，您可以使用 GDC 控制台、gdcloud CLI 创建 IAMRoleBinding，也可以使用 kubectl CLI 应用自定义资源清单（YAML 文件）。
例如，如需允许团队成员查看项目中的虚拟机，您可以在该项目的范围内创建一个 IAMRoleBinding，将成员的身份链接到查看者角色。当成员尝试查看虚拟机时，GDC 会检查其有效角色绑定，确认分配的角色包含所需的权限，并授权该请求。
虽然 GDC 控制台和 gdcloud CLI 会自动连接到您的资源，但使用 kubectl CLI 进行直接 API 访问需要通过生成 kubeconfig 文件向托管该资源的特定 Kubernetes 集群或 API 服务器进行身份验证。如需了解详情，请参阅 登录并生成 kubeconfig 文件。
如需详细了解如何管理角色绑定，请参阅 授予和撤消访问权限。
GDC 网闸隔离配置 IAM 与 Google Cloud
如果您有在管理访问权限的经验 Google Cloud， GDC 使用类似的概念，但以 不同的方式实现这些概念，以便在基于 Kubernetes 的 air-gapped 基础架构中运行。
下表比较了 GDC 中的 IAM 和 Google Cloud：
| 功能 | 说明 | GDC air-gapped | Google Cloud |
|---|---|---|---|
| 用户身份（身份验证） | 用于对人类用户进行身份验证的身份系统。 |
使用所需的 IdP 前缀（例如 idpprefix-user@domain.com）与您的外部 IdP 联合。 |
Google 账号（例如 Gmail）或通过 Cloud Identity 或 Google Workspace 联合的公司身份。 |
| 授权引擎 | 用于评估和强制执行权限的基础系统。 | 主要是 Kubernetes 基于角色的访问权限控制 (RBAC)，其中访问 请求由 API 服务器根据角色 绑定在本地进行评估。您可以使用组织政策来设置资源 限制。 | Google 的全球 Cloud IAM 服务。集中评估针对附加到资源层次结构中任何级别的访问权限政策的 API 请求。 |
| 角色绑定 | 成员如何映射到特定资源的角色。 |
单个 IAMRoleBinding 自定义资源。每个绑定
是将成员链接到一个角色的对象。IAM 角色
权限纯粹是附加权限（拒绝规则可以通过组织政策单独配置）。
|
附加到每个资源、 文件夹或组织的单个 IAM 访问权限政策。包含将成员映射到 角色的多个绑定，并支持条件规则或拒绝规则。 |
| 服务账号 | 应用和自动化工作负载使用的非人类身份。 |
在特定项目
(ProjectServiceAccount) 中创建的本地服务账号。公钥存储在
集群中，而私钥由客户端在本地管理和保护。
|
由 Google 集中管理的全球身份。凭据可以由 Google 自动管理，也可以下载为密钥文件以从任何位置进行身份验证。 |
| 资源层次结构 | 用于组织资源和继承权限的容器结构。 | 两层层次结构：组织 > 项目 | 多层层次结构：组织 > 文件夹 > 项目 |
| 多可用区权限范围 | 权限在可用区 或区域之间的评估和传播方式。 | 使用由全球 API 服务器管理的 Kubernetes RBAC，该服务器会协调 各个可用区 API 服务器之间的角色绑定并复制这些绑定，以便访问权限默认应用于所有可用区。 | 采用全代管式全球 IAM 服务。在任何资源级别分配的权限本质上都是全局性的，并且会自动应用于所有区域和可用区。 |
| 客户端工具 | 用于管理访问权限的主要界面、CLI 工具和 API。 | GDC 控制台、gdcloud CLI 和 KRM API。 | Google Cloud 控制台、gcloud CLI 以及 REST 或 gRPC API。 |
| 直接 API 访问 | 工具和脚本如何进行身份验证以使用 API 直接管理资源。 | 使用 kubectl CLI 进行直接 API 访问需要通过生成 kubeconfig 文件向托管该资源的特定 Kubernetes 集群或 API 服务器进行身份验证。（GDC 控制台和 gdcloud CLI 会自动连接到资源。） |
使用 gcloud 或 REST/gRPC
端点进行直接 API 访问时，会使用集中式凭据
(gcloud auth login)，这些凭据在全球范围内适用于所有服务，而无需特定于集群的登录。
|