借助 Google Distributed Cloud (GDC) 网闸隔离配置中的 Identity and Access Management (IAM)，您可以控制谁有权访问哪些资源，以及他们可以对这些资源执行哪些操作。
了解 IAM 在 GDC 中的运作方式有助于您有效管理访问权限，确保成员拥有履行其角色所需的权限，同时维护经过网闸隔离的环境的安全。
本文档面向平台管理员和应用运维人员群组（例如 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 配置了前缀
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 集群）。
如需了解详情，请参阅资源层次结构和多可用区 Universe 的权限控制。
如何授权访问
GDC 主要使用基于角色的访问权限控制 (RBAC) 模型来管理和授权访问。在 RBAC 模型中，您不会直接向单个用户或工作负载分配权限。而是通过在特定资源范围向成员分配角色来确定访问权限。
GDC 使用以下 Kubernetes 自定义资源实现 RBAC：
IAMRole：定义一组特定的权限。IAMRoleBinding：在组织或项目范围内将成员（人类用户、群组或服务账号）与IAMRole相关联。
如需授予对组织或项目资源的访问权限，您可以使用 GDC 控制台、gdcloud CLI 创建 IAMRoleBinding，也可以使用 kubectl CLI 应用自定义资源清单（YAML 文件）。
例如，如需允许团队成员查看项目中的虚拟机，您可以在该项目的范围内创建一个 IAMRoleBinding，将该成员的身份与 Viewer 角色相关联。当成员尝试查看虚拟机时，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 前缀（例如 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)，这些凭据在全球范围内适用于所有服务，无需特定于集群的登录。
|