员工身份联合

本文档介绍了员工身份联合的关键概念。

什么是员工身份联合？

通过员工身份联合，您可以使用外部身份提供方 (IdP) 对员工（用户群组，例如员工、合作伙伴和承包商）通过 IAM 进行身份验证和授权，以便用户能够访问 Google Cloud 服务。借助员工身份联合，您无需像使用 Cloud Identity 的 Google Cloud Directory Sync (GCDS) 一样将用户身份从现有 IdP 同步到 Google Cloud 身份。员工身份联合扩展了 Google Cloud 的身份功能，可支持基于属性的非同步单点登录。

用户进行身份验证后，系统会使用从 IdP 收到的信息确定对 Google Cloud 资源的访问权限范围。

您可以将员工身份联合与任何支持 OpenID Connect (OIDC) 或 SAML 2.0 的 IdP（如 Microsoft Entra ID、Active Directory Federation Services [AD FS]、Okta 等）搭配使用。

员工身份池

借助员工身份池，您可以管理员工身份群组及其对 Google Cloud 资源的访问权限。

通过池，您可以执行以下操作：

  • 对用户身份进行分组；例如 employees 或 partners
  • 授予对整个池或部分池的 IAM 访问权限。
  • 从一个或多个 IdP 联合身份。
  • 为需要类似访问权限的用户群组定义政策。
  • 指定特定于 IdP 的配置信息，包括属性映射和属性条件。
  • 为第三方身份启用 Google Cloud CLI 和 API 访问权限。
  • 记录池中的用户对 Cloud Audit Logs 的访问以及池 ID。

您可以创建多个池。如需查看描述此类方法的示例，请参阅示例：多个员工身份池。

池是在 Google Cloud 组织级层配置的。因此，只要您拥有查看池的相应 IAM 权限，就可将池用于组织中的所有项目和文件夹。首次为组织设置员工身份联合时，需要指定池名称。在 IAM 允许政策中，您可以通过名称来引用池。因此，我们建议您在为池命名时，使其能够清楚地描述其所包含的身份。

员工身份池提供方

员工身份池提供方是描述 Google Cloud 组织和 IdP 之间关系的实体。

员工身份联合遵循 OAuth 2.0 令牌交换规范 (RFC 8693)。您可以将外部身份提供方的凭据提供给 Security Token Service，该服务会验证凭据中的身份，然后通过交换返回短期 Google Cloud 访问令牌。

OIDC 流类型

对于 OIDC 提供方，员工身份联合支持授权代码流程和隐式流。授权代码流被认为是最安全的，因为在用户进行身份验证后，令牌会通过单独的安全后端事务直接从 IdP 返回到 Google Cloud。因此，代码流事务可以检索任何大小的令牌，因此您可以将更多声明用于属性映射和属性条件。而在隐式流中，ID 令牌会从 IdP 返回到浏览器。令牌受单个浏览器网址大小限制的约束。

Google Cloud 员工身份联合控制台

员工身份池中的用户可以访问 Google Cloud 员工身份联合控制台，也称为控制台（联合）。这些用户可以通过该控制台对支持员工身份联合的 Google Cloud 产品的界面进行访问。

特性映射

您的 IdP 会提供一些属性（某些 IdP 将其称为声明）。属性包含有关用户的信息。您可以使用通用表达式语言 (CEL) 映射这些属性以供 Google Cloud 使用。

本部分介绍 Google Cloud 提供的一组必需属性和可选属性。

您还可以在 IdP 中定义自定义属性，以供特定 Google Cloud 产品使用；例如在 IAM 允许政策中使用。

属性映射的大小上限为 4 KB。

属性如下所示：

  • google.subject（必需）：用来对用户进行身份验证的唯一标识符。通常是 JWT 的主题断言，因为 Cloud Audit Logs 日志将此字段的内容记录为主账号。您可以使用此字段配置 IAM 以进行授权决策。我们建议您不要使用可变值，因为如果您更改了 IdP 用户目录中的值，则用户会失去访问权限。

    长度上限为 127 个字节。

  • google.groups（可选）：进行身份验证的用户所属的群组集合。您可以使用生成字符串数组的 CEL 子集来配置逻辑表达式。您还可以使用此字段配置 IAM 以进行授权决策。google.groups 的限制如下：

    • 我们建议您将群组名称长度限制在 100 个字符以内。

    • 如果一个用户与超过 100 个群组相关联，请定义一组较小的群组，并且仅在用于将用户联合到 Google Cloud 的断言中包含这些群组。 如果一个用户属于 100 个群组以上，则身份验证会失败。

    • 如果您使用此属性在 IAM 中授予访问权限，则所映射群组中的每个成员都将获得访问权限。因此，我们建议您确保只有组织中的授权用户才能修改所映射群组的成员资格。

  • google.display_name（可选）：用于在 Google Cloud 控制台中设置已登录用户的名称的特性。此特性不能用于 IAM 允许政策和特性条件。

    长度上限为 100 个字节。

  • google.profile_photo（可选）：用户的照片缩略图的网址。我们建议照片尺寸为 400x400 像素。设置此属性后，图片会在 Google Cloud 控制台中显示为用户的个人资料照片。如果未设置该值或无法获取该值，系统会显示一个通用用户图标。此属性不能用于 IAM 允许政策或属性条件。

  • google.posix_username（可选）：符合 POSIX 标准的唯一用户名字符串，可用于：

    此属性不能用于 IAM 允许政策和属性条件。最大长度为 32 个字符。

  • attribute.KEY（可选）：用户 IdP 令牌中存在的外部 IdP 定义的属性。您可以使用自定义属性在 IAM 允许政策中定义自己的授权策略。

    例如，在您的 IdP 中，您可以选择将用户的成本中心等属性定义为 costcenter = "1234"，然后按如下方式引用正文：

    principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.costcenter/1234

    向此正文标识符授予 Google Cloud 资源的访问权限后，在 IdP 中配置为将 costcenter 属性设为 1234 的所有身份都将拥有对这些资源的访问权限。

    您最多可以配置 50 个自定义属性映射规则。每个此类规则的大小上限为 2048 个字符。

    虽然我们对您可以映射的属性没有限制，但我们强烈建议您选择值稳定的属性。例如，attribute.job_description 等属性可能会因各种原因而发生变化（例如为了提高其可读性）。作为替代方案，请考虑使用 attribute.role。后者的变化表明分配责任的改变，并会反映在对用户授予的访问权限上。

您可以使用标准 CEL 函数转换属性值。您也可以使用以下自定义函数：

  • split 函数按指定的分隔符值拆分字符串。例如，如需通过在电子邮件地址属性中的 @ 位置处拆分其值并使用第一个字符串，来提取 username 属性，请使用以下属性映射：

    attribute.username=assertion.email.split("@")[0]

  • join 函数按指定的分隔符值联接字符串列表。例如，如需通过以 . 作为分隔符串联字符串列表来填充自定义属性 department，请使用以下属性映射：

    attribute.department=assertion.department.join(".")

特性条件

属性条件是可选的 CEL 表达式，您可以通过这些表达式对 Google Cloud 接受的身份属性设置限制条件。

使用属性条件的好处包括：

  • 您可以使用属性条件仅允许一部分外部身份向您的 Google Cloud 项目进行身份验证。例如，您可能只想允许特定团队中的身份登录，尤其是在使用公共 IdP 时。另一个例子是，您可能希望允许会计团队登录，但不允许工程团队登录。
  • 借助属性条件，您可以防止用于其他平台的凭据被用在 Google Cloud，反之亦然。这有助于避免混淆代理问题。

与 GitHub 或其他多租户身份提供方联合时使用属性条件

员工身份联合不会保留用户账号目录，而是实现基于声明的身份。因此，如果两个令牌由同一身份提供方 (IdP) 颁发且其声明映射到同一 google.subject 值时，则系统会假定这两个令牌用于标识同一用户。如需了解哪个 IdP 颁发了令牌，员工身份联合会检查并验证令牌的颁发者网址。

多租户 IdP（例如 GitHub 和 Terraform Cloud）在其所有租户中使用单个颁发者网址。对于这些提供方，颁发者网址标识所有 GitHub 或 Terraform Cloud 组织，而不是特定的 GitHub 或 Terraform Cloud 组织。

使用这些身份提供方时，让员工身份联合检查令牌的颁发者网址以确保令牌来自可信来源且其声明可信任是不够的。如果您的多租户 IdP 具有单个颁发者网址，我们建议您必须使用属性条件来确保仅向正确的租户授予访问权限。

在 IAM 政策中表示员工池用户

下表显示了用于向单个用户、用户群组、执行特定声明的用户或员工池中的所有用户授予角色的主账号标识符。

身份 标识符格式
员工身份池中的单个身份 principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE
群组中的所有员工身份 principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/GROUP_ID
具有特定属性值的所有员工身份 principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
员工身份池中的所有身份 principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/*

JSON Web 密钥

员工池提供方可以在 /.well-known/openid-configuration 文档的 jwks_uri 字段中访问您的 IdP 提供的 JSON Web 密钥 (JWK)。如果您的 OIDC 提供方未提供此信息，或者您的颁发者无法公开访问，则您可以在创建或更新 OIDC 提供方时手动上传 JWK。

限制跨组织访问

员工身份池主账号无法直接访问他们所属组织之外的资源。但是，如果主账号被授予在组织内模拟服务账号的权限，则可以绕过此限制条件，因为服务账号没有同等限制。

员工池用户项目

大多数 Google Cloud API 会对包含 API 请求所访问资源的项目进行结算和配额用量计算。这些 API 称为“基于资源的 API”。少数 Google Cloud API 会对与客户端关联的项目进行结算和配额用量计算，这些 API 称为“基于客户端的 API”。用于结算和配额用途的项目称为“配额项目”。

创建员工身份联合配置文件时，您需要指定员工池用户项目。此项目用于向应用调用的 Google API 标识该应用。员工池用户项目也会用作基于客户端的 API 的默认配额项目，除非您使用 gcloud CLI 发起 API 请求。您必须拥有您所指定项目的 serviceusage.services.use 权限（包含在 Service Usage Consumer (roles/serviceusage.serviceUsageConsumer) 角色中）。

如需详细了解配额项目、基于资源的 API 和基于客户端的 API，请参阅配额项目概览。

示例：多个员工身份池

本部分包含一个示例，说明了多个池的典型用法。

您可以为员工创建一个池，为合作伙伴创建另一个池。跨国组织可能会为其组织中的不同部门创建单独的池。您可以通过池进行分布式管理，其中不同的群组可以独立管理其特定池，而角色也只会授予给该池中的身份。

例如，假设一家名为 Enterprise Example Organization 的公司与另一家名为 Partner Example Organization Inc 的公司合作，提供 Google Kubernetes Engine (GKE) DevOps 服务。为了使 Partner Example Organization 的员工能够提供服务，他们必须有权访问 Google Kubernetes Engine (GKE) 和 Enterprise Example Organization 组织中的其他 Google Cloud 资源。Enterprise Example 组织已经拥有一个名为 enterprise-example-organization-employees 的员工身份池。

为了让 Partner Example Organization 能够管理对 Enterprise Example Organization 资源的访问权限，Enterprise Example Organization 会为 Partner Example Organization 的员工用户创建一个单独的员工池，以便 Partner Example Organization 可以管理它。Enterprise Example Organization 会将该员工池提供给 Partner Example Organization 的管理员。Partner Example Organization 的管理员会使用自己的 IdP 向其员工授予访问权限。

为此，Enterprise Example Organization 的管理员会执行以下任务：

  1. 在 Enterprise Example Organization 的 IdP 中为 Partner Example Organization 的管理员创建一个身份（例如 partner-organization-admin@example.com），该身份已经在名为 enterprise-example-organization-employees 的池中配置。

  2. 创建一个名为 example-organization-partner 的新员工池。

  3. 为 example-organization-partner 池创建以下允许政策：

    {
  "bindings": [
    {
      "role": "roles/iam.workforcePoolEditor",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/enterprise-example-organization-employees/subject/partner-organization-admin@example.com"
      ]
    }
  ]
}

  4. 为 example-organization-partner 池授予他们需要在 Enterprise Example Organization 组织中访问的资源的相应角色。

Partner Example Organization 的管理员现在可以配置 example-organization-partner 池以与其 IdP 相关联。然后，他们可以允许 Partner Example Organization 的员工使用自己组织的 IdP 凭据登录。登录后，Partner Example Organization 的员工用户便可以访问相应的 Google Cloud 资源，但会受 Enterprise Example Organization 定义的政策所约束。

简化访问权限管理

在大型企业中，IT 管理员通常会在访问权限控制模型中创建安全群组。安全群组控制对内部资源的访问权限。此外，公司通常会为员工和合作伙伴分别创建额外的群组，以将这种访问权限控制模型扩展到云资源。这可能导致深度嵌套群组数量激增，而这又会增加管理难度。

您的组织可能还提供政策来限制您可以创建的群组数量，以使用户目录层次结构保有一定的平面度。为了防止 IAM 政策配置错误并限制群组增长，一种更好的解决方案是使用多个池，以根据不同的组织单元、业务部门和合作伙伴组织对用户进行更好的分隔。然后，您可以引用这些池及其包含的群组来定义 IAM 政策（请参阅“配置 IAM”步骤中的示例）。

VPC Service Controls 限制

员工身份联合、员工池配置 API 和 Security Token Service API 不支持 VPC Service Controls。但是，员工池用户可以访问的 Google Cloud 产品支持 VPC Service Controls。如需了解详情，请参阅 VPC Service Controls 的支持的产品和限制页面。

员工身份联合和重要联系人

如需接收与您的组织或 Google Cloud 产品更改相关的重要信息，您必须在使用员工身份联合时提供重要联系人。您可以通过 Cloud Identity 电子邮件地址与 Cloud Identity 用户联系，但使用重要联系人与员工身份联合用户联系。

使用 Google Cloud 控制台创建或管理员工身份池时，您会看到一个横幅，要求您配置法务和中止类别的重要联系人。或者，如果您没有单独的联系人，也可以在全部类别中定义联系人。提供联系人后，系统会移除横幅。

后续步骤