借助 Google Distributed Cloud (GDC) 气隙设备中的 Identity and Access Management (IAM)，您可以控制哪些人可以访问哪些资源，以及他们可以对这些资源执行哪些操作。
了解 IAM 在 GDC 中的运作方式有助于您有效地管理访问权限，确保成员拥有执行其角色所需的权限，同时维护气隙环境的安全性。
访问权限控制模型
GDC 围绕三个核心组件构建访问权限： 成员（谁）、 角色（什么）和 资源范围（哪里）。
访问权限控制包含两个不同的阶段：证明您的身份（身份验证）和确定您可以执行的操作（授权）：
- 身份验证： GDC 不存储用户账号或密码。GDC 可以利用其捆绑的 Keycloak 身份提供方 (IdP)，也可以连接到您组织的 IdP，以便您可以使用自己的凭据登录。
- 授权： 身份验证后，GDC IAM 会检查您分配的角色，以确定您可以访问哪些资源以及可以执行哪些操作。
成员
成员是您可以授予资源访问权限的身份。 GDC 根据您管理成员的位置将成员分为两大类：人类身份和非人类身份。
人类身份
人类身份是指登录 GDC 的用户和群组。GDC 不存储用户账号或密码，而是可以利用其捆绑的 Keycloak IdP，也可以使用 OpenID Connect (OIDC) 或 SAML 2.0 等标准身份联合协议连接到您组织的现有登录系统（例如 Active Directory、LDAP 或 Okta）。
人类身份有两种类型：
- 用户： 使用自己的凭据登录系统的个人人类用户。
- 群组： 在 Keycloak 或您组织的 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 提供了一个全面的预定义角色库，这些角色是根据特定的工作职能和服务量身定制的（从 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 的气隙基础架构中运行。
下表比较了 GDC 中的 IAM 和 Google Cloud：
| 功能 | 说明 | GDC 网闸隔离配置 | Google Cloud |
|---|---|---|---|
| 用户身份（身份验证） | 用于对人类用户进行身份验证的身份系统。 |
与您的外部 IdP 联合，或使用捆绑的 Keycloak
IdP 进行管理，使用所需的 IdP 前缀（例如，
idpprefix-user@domain.com)。
|
Google 账号（例如 Gmail）或通过 Cloud Identity 或 Google Workspace 联合的企业身份。 |
| 授权引擎 | 用于评估和强制执行权限的基础系统。 | 主要是 Kubernetes 基于角色的访问权限控制 (RBAC)，其中 API 服务器根据角色绑定在本地评估访问权限请求。 | Google 的全球 Cloud IAM 服务。集中评估针对附加到资源层次结构中任何级别的访问权限政策的 API 请求。 |
| 角色绑定 | 成员如何映射到特定资源的角色。 |
单个 IAMRoleBinding 自定义资源。每个绑定
是将成员链接到一个角色的对象。IAM 角色
权限纯粹是附加权限。
|
附加到每个资源、 文件夹或组织的单个 IAM 访问权限政策。包含将成员映射到 角色的多个绑定，并支持条件规则或拒绝规则。 |
| 服务账号 | 应用和自动化工作负载使用的非人类身份。 |
在特定项目
(ProjectServiceAccount) 中创建的本地服务账号。公钥存储在
集群中，而私钥由客户端在本地管理和保护。
|
由 Google 集中管理的全局身份。凭据可以由 Google 自动管理，也可以下载为密钥文件以从任何位置进行身份验证。 |
| 资源层次结构 | 用于组织资源和继承权限的容器结构。 | 双层层次结构：组织 > 项目 | 多层层次结构：组织 > 文件夹 > 项目 |
| 客户端工具 | 用于管理访问权限的主要界面、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)，这些凭据在全球范围内适用于所有服务，而无需特定于集群的登录。
|