Principal Access Boundary Policy

借助主账号访问权限边界 (PAB) 政策，您可以限制主账号可以访问的资源。

例如，您可以使用主账号访问边界政策来阻止主账号访问其他组织中的资源，这有助于防止钓鱼式攻击或数据渗漏。

如需了解 Identity and Access Management (IAM) 提供的其他类型的访问权限控制政策，请参阅政策类型。

主账号访问边界政策的工作原理

默认情况下，身份有权访问任何 Google Cloud 资源。这意味着，如果主账号对资源具有权限且未被拒绝该权限，则可以使用该权限访问资源。

借助主账号访问权限边界政策，您可以限制主账号可以访问的资源。如果主账号访问权限边界政策使主账号无法访问某个资源，则无论主账号被授予什么角色，其对该资源的访问权限都会受到限制。

当主账号尝试访问不符合其访问资格的资源时，主账号访问权限边界政策可以阻止部分（但不是全部）Identity and Access Management (IAM) 权限。如需详细了解哪些权限会被屏蔽，请参阅主账号访问权限边界可以屏蔽的权限。

Principal Access Boundary Policy 由主账号访问权限边界规则组成。每条主账号访问边界规则都会定义一组受影响的主账号可以访问的资源。您最多可以在组织中创建 1000 个主账号访问权限边界政策。

创建主账号访问边界政策后，您需要创建政策绑定，以将该政策应用于一组主账号。

主账号可以受一个或多个主账号访问权限边界政策的约束。每个主账号只能访问这些政策中列出的资源。对于所有其他资源，即使您向主账号授予了相应资源的角色，主账号对该资源的访问权限也会受到限制。

由于主账号访问权限边界政策与主账号相关联，而非与资源相关联，因此您可以使用这些政策来阻止主账号访问您不拥有的资源。例如，设想以下场景：

主账号访问权限边界政策阻止访问某个资源

主账号访问权限边界政策阻止访问某个资源

  • 主账号 Tal (tal@altostrat.com) 属于 Google Workspace 组织 altostrat.com。
  • Tal 获得了另一个组织 cymbalgroup.com 中 Cloud Storage 存储桶的 Storage Admin (roles/storage.admin) 角色。此角色包含 storage.objects.get 权限，查看存储桶中的对象需要此权限。
  • cymbalgroup.com 中没有任何拒绝政策会阻止 Tal 使用 storage.objects.get 权限。

仅使用允许和拒绝政策，altostrat.com 无法阻止 Tal 查看此外部存储桶中的对象。没有任何 altostrat.com 主账号有权修改存储桶的允许政策，因此无法撤消 Tal 的角色。他们也没有权限在 cymbalgroup.com 中创建任何拒绝访问政策，因此无法使用拒绝访问政策阻止 Tal 访问存储桶。

不过，借助主账号访问权限边界政策，altostrat.com 管理员可以确保 Tal 无法查看 cymbalgroup.com 存储桶或 altostrat.com 以外的任何存储桶中的对象。为此，管理员可以创建一个主账号访问权限边界政策，声明 altostrat.com 主账号只能访问 altostrat.com 中的资源。然后，他们可以创建政策绑定，以将此政策附加到组织 altostrat.com 中的所有主账号。有了这样的政策，Tal 将无法查看 cymbalgroup.com 存储桶中的对象，即使他们已获授该存储桶的 Storage Admin 角色也是如此。

应急开启评估

在主账号访问边界政策预览版期间，主账号访问边界政策会在发生故障时保持开放状态。这意味着，如果 IAM 无法评估主账号访问权限边界政策，则会忽略主账号访问权限边界政策，并继续评估相关的允许和拒绝政策。

Principal Access Boundary Policy 阻止的权限

当主账号尝试访问不符合其访问资格要求的资源时，主账号访问权限边界政策会阻止其使用某些（但不是所有）Identity and Access Management (IAM) 权限来访问该资源。

如果主账号访问权限边界政策阻止某项权限，IAM 会针对该权限强制执行主账号访问权限边界政策。换言之，它会阻止任何不符合访问资源条件的主账号使用该权限访问资源。

如果主账号访问权限边界政策不会阻止某项权限，则主账号访问权限边界政策对主账号能否使用该权限没有任何影响。

例如，假设主账号 Lee (lee@example.com) 被授予 Dataflow Developer 角色 (roles/dataflow.developer)。此角色包含 dataflow.jobs.snapshot 权限，可让 Lee 获取 Dataflow 作业的快照。Lee 还受主账号访问边界政策的约束，因此无法访问 example.com 以外的资源。不过，如果主账号访问权限边界政策未屏蔽 dataflow.jobs.snapshot 权限，Lee 仍可在 example.com 以外的组织中为 Dataflow 作业截取快照。

Principal Access Boundary Policy 阻止的权限取决于 Principal Access Boundary 强制执行版本。

主账号访问权限边界强制执行版本

每个主账号访问权限边界政策都指定了一个执行版本，该版本标识了主账号访问权限边界政策可以屏蔽的预定义 IAM 权限列表。您可以在创建或更新主账号访问权限边界政策时指定强制执行版本。如果您未指定强制执行版本，IAM 会使用最新的强制执行版本，并会在您更新该版本之前继续使用该版本。

IAM 会定期添加新的主账号访问权限边界强制执行版本，以阻止用户获得额外的权限。每个新版本还可以屏蔽上一个版本中的所有权限。

如需在新的强制执行版本中屏蔽权限，您必须更新主账号访问权限边界政策，以使用新版本。如果您希望强制执行版本在发布新版本时自动更新，则可以在创建政策时使用值 latest。不过，我们不建议使用此值，因为这可能会导致主账号意外失去对资源的访问权限。

如需查看每个执行版本所屏蔽的权限的完整列表，请参阅Principal Access Boundary Policy 屏蔽的权限。

将主账号访问权限边界政策绑定到主账号集

如需将主账号访问边界政策绑定到主账号集，请创建政策绑定，以指定您要强制执行的主账号访问边界政策以及要针对其强制执行的主账号集。将政策绑定到主账号集后，该主账号集中的主账号只能访问主账号访问权限边界政策规则中包含的资源。

您可以将主账号访问边界政策绑定到任意数量的主账号集。每个主账号集最多可以有 10 个主账号访问权限边界政策绑定到它。

如需了解如何管理主账号访问边界政策，请参阅创建和应用主账号访问边界政策。

支持的主账号集

下表列出了您可以将主账号访问权限边界政策绑定到的主账号集类型。每行包含以下内容：

  • 主账号集的类型
  • 该类型主账号集中的主账号
  • 该类型主账号集的 ID 格式
  • 为该类型的主账号集绑定政策的 Resource Manager 资源（项目、文件夹或组织）
主账号集 详情 政策绑定的父级资源
员工身份池

包含指定员工身份池中的所有身份。

格式：//iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID

包含员工身份池的组织
工作负载身份池

包含指定工作负载身份池中的所有身份。

格式：//iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_POOL_ID

包含工作负载身份池的项目
Google Workspace 网域

包含指定 Google Workspace 网域中的所有身份。

格式：//iam.googleapis.com/locations/global/workspace/WORKSPACE_ID

如需了解如何查找您的 Workspace ID，请参阅查找您的客户 ID。

与 Google Workspace 域名关联的组织
项目主账号集

包含指定项目中的所有服务账号和工作负载身份池。

格式：//cloudresourcemanager.googleapis.com/projects/PROJECT_ID

项目
文件夹的主账号集

包含指定文件夹中所有项目中的所有服务账号和所有工作负载身份池。

格式：//cloudresourcemanager.googleapis.com/folders/FOLDER_ID

文件夹
组织的主账号集

包含以下身份：

  • 与您的 Google Workspace 客户 ID 相关联的所有网域中的所有身份
  • 贵组织中的所有员工身份池
  • 组织中任何项目中的所有服务账号和工作负载身份池

格式：//cloudresourcemanager.googleapis.com/organizations/ORGANIZATION_ID

组织

主账号访问边界政策的条件式政策绑定

您可以在 Principal Access Boundary Policy 的政策绑定中使用条件表达式，以进一步细化政策适用的主账号。

政策绑定的条件表达式由一个或多个通过最多 10 个逻辑运算符（&&、|| 或 !）进行联接的语句组成。每个语句表示一条适用于政策绑定且基于属性的控制规则，并最终确定政策是否适用。

您可以在政策绑定的条件中使用 principal.type 和 principal.subject 属性。政策绑定条件中不支持其他属性。

  • principal.type 属性表示请求中包含哪种类型的主账号，例如工作负载身份池中的服务账号或身份。您可以使用此属性的条件来控制主账号访问权限边界政策适用于哪些类型的主账号。

    例如，如果您将以下条件表达式添加到主账号访问权限边界政策的绑定中，则该政策仅适用于服务账号：

    principal.type == 'iam.googleapis.com/ServiceAccount'

  • principal.subject 属性表示请求中主账号的身份，例如 cruz@example.com。您可以使用此属性的条件来精确控制哪些主账号受主账号访问权限边界政策的约束。

    例如，如果您将以下条件表达式添加到主账号访问权限边界政策的绑定中，则该政策将不会应用于用户 special-admin@example.com：

    principal.subject != 'special-admin@example.com'

如需详细了解可用于这些条件的值，请参阅条件属性参考。

示例：使用条件来减少主账号有资格访问的资源

在 Principal Access Boundary Policy 绑定中使用条件的一种方式是减少单个主账号有资格访问的资源。

假设您有一个电子邮件地址为 dev-project-service-account@dev-project.iam.gserviceaccount.com 的服务账号 dev-project-service-account。此服务账号受主账号访问权限边界政策的约束，该政策使主账号有权访问组织 example.com 中的所有资源。此政策将附加到 example.com 组织的主账号集。

您决定不希望 dev-project-service-account 有资格访问 example.com 中的所有资源，只希望它有资格访问 dev-project 中的资源。但是，您不希望更改 example.com 主账号集中的其他主账号有权访问的资源。

如需进行此更改，请按照减少主账号有权访问的资源的步骤操作，但要为政策绑定添加条件，而不是删除它：

  1. 您确认 dev-project-service-account 受限的唯一主账号访问权限边界政策是使主账号有资格访问 example.com 中的所有资源的政策。

  2. 您可以创建新的主账号访问边界政策，使主账号有权访问 dev-project 中的资源，并将其附加到 dev-project 的主账号集。您可以在政策绑定中使用以下条件，以确保仅对 dev-project-service-account 强制执行该政策：

    "condition": {
  "title": "Only dev-project-service-account",
  "expression": "principal.type == 'iam.googleapis.com/ServiceAccount' && principal.subject == 'dev-project-service-account@dev-project.iam.gserviceaccount.com'"
}

  3. 您将 dev-project-service-account 从主账号访问权限边界政策中排除，使主账号有权访问 example.com 中的所有资源。为此，您需要在将主账号访问权限边界政策附加到组织的主账号集的政策绑定中添加以下条件：

    "condition": {
  "title": "Exempt dev-project-service-account",
  "expression": "principal.subject != 'dev-project-service-account@dev-project.iam.gserviceaccount.com' || principal.type != 'iam.googleapis.com/ServiceAccount'"
}

    如需了解如何更新现有的 Principal Access Boundary Policy，请参阅修改 Principal Access Boundary Policy。

向政策绑定中添加此条件后，dev-project-service-account 将不再有资格访问 example.com 中的所有资源，而是仅有资格访问 dev-project 中的资源。

政策互动

IAM 会结合您的允许和拒绝政策以及其他主账号访问权限边界政策来评估每个主账号访问权限边界政策。所有这些政策都用于确定主账号能否访问资源。

与其他类型的政策互动

当主账号尝试访问资源时，IAM 会评估所有相关的主账号访问权限边界、允许和拒绝政策，以查看主账号是否有权访问该资源。如果这些政策中有任何一项表明主账号不应有权访问相应资源，IAM 会禁止访问。

因此，如果主账号访问权限边界政策会阻止主账号访问某个资源，则无论附加到该资源的允许和拒绝政策如何，IAM 都会阻止他们访问该资源。

此外，仅凭主账号访问权限边界政策并不能让主账号访问资源。虽然主账号访问权限边界政策可以让主账号有资格访问资源，但只有允许政策可以实际授予主账号对资源的访问权限。

如需详细了解 IAM 政策评估，请参阅政策评估。

主账号访问权限边界政策之间的互动

如果任何主账号访问边界政策使主账号有资格访问某项资源，则无论该主账号是否受其他主账号访问边界政策的约束，它都有权访问该资源。因此，如果主账号已受限于主账号访问权限边界政策，则您无法添加主账号访问权限边界政策来减少主账号的访问权限。

例如，假设主账号 Dana (dana@example.com) 受单个主账号访问权限边界政策 prod-projects-policy 的约束。此政策使主账号有资格访问 prod-project 中的资源。Dana 会受到此政策的约束，因为该政策已绑定到其组织的主账号集。

您可以创建新的主账号访问权限边界政策 dev-staging-projects-policy，使主账号有权访问 dev-project 和 staging-project 中的资源，然后将其绑定到组织的主账号集。

由于这些主账号访问边界政策，Dana 有权访问 dev-project、staging-project 和 prod-project 中的资源。

如果您想减少 Dana 有资格访问的资源，则需要修改或移除 Dana 受限的 Principal Access Boundary Policy。

例如，您可以修改 dev-staging-projects-policy，使其不让主账号有权访问 dev-project 中的资源。这样一来，Dana 将仅有权访问 staging-project 和 prod-project 中的资源。

或者，您也可以通过删除将 prod-projects-policy 绑定到组织的主账号集的政策绑定来移除它。这样一来，Dana 将只能访问 dev-project 和 staging-project 中的资源。

不过，这些更改不仅会影响 Dana，还会影响受修改的主账号访问权限边界政策和绑定约束的其他主账号。如果您想减少单个主账号有权访问的资源，请使用条件式政策绑定。

政策继承

主账号访问边界政策会附加到主账号集，而不是 Resource Manager 资源。因此，它们不会像允许和拒绝政策那样通过资源层次结构进行继承。

不过，Resource Manager 父级资源（即文件夹和组织）的主账号集始终包含其子级主账号集中的所有主账号。例如，如果某个主账号包含在项目的主账号集中，则该主账号也会包含在任何父级文件夹或组织的主账号集中。

例如，假设有一个名为 example.com 的组织。此组织与域名 example.com 相关联，并具有以下 Resource Manager 资源：

example.com 的资源层次结构

example.com 的资源层次结构

  • 某个组织，例如 example.com
  • 项目 project-1，是组织的子级
  • 文件夹 folder-a，是组织的子级
  • 两个项目 project-2 和 project-3，它们是 folder-a 的子级

这些资源的主账号集包含以下身份：

主账号集 网域 example.com 中的 Google Workspace 身份 example.com 中的员工身份联合池 project-1 中的服务账号和工作负载身份池 project-2 中的服务账号和工作负载身份池 project-3 中的服务账号和工作负载身份池
为 example.com 设置的主账号
为 folder-a 设置的主账号
为 project-1 设置的主账号
为 project-2 设置的主账号
为 project-3 设置的主账号

因此，以下主账号会受到以下主账号访问权限边界政策的影响：

  • example.com 网域中的 Google Workspace 身份位于 example.com 的主账号集中，并会受到绑定到该主账号集的主账号访问权限边界政策的影响。

  • project-1 中的服务账号位于 project-1 和 example.com 的主账号集中，并会受到绑定到这两个主账号集中的任何主账号访问边界政策的影响。

  • project-3 中的服务账号属于 project-3、folder-a 和 example.com 的主账号集，并且会受到绑定到这些主账号集的任何主账号访问边界政策的影响。

主账号访问边界政策和缓存资源

某些 Google Cloud 服务会缓存公开可见的资源。例如，Cloud Storage 会缓存可供公开读取的对象。

主账号访问边界能否阻止不符合条件的主账号查看公开可见的资源取决于资源是否已缓存：

  • 如果资源已缓存，则主账号访问边界无法阻止主账号查看该资源
  • 如果资源未缓存，则主账号访问边界会阻止不符合条件的主账号查看该资源

在所有情况下，主账号访问权限边界政策都会阻止不符合条件的主账号修改或删除公开可见的资源。

主账号访问边界政策的结构

Principal Access Boundary Policy 是元数据和 Principal Access Boundary Policy 详情的集合。元数据提供政策名称和创建时间等信息。政策详情定义了政策的功能，例如，受影响的主账号有资格访问的资源。

例如，以下 Principal Access Boundary Policy 会使受该政策约束的主账号有资格访问组织中 ID 为 0123456789012 的资源。

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "uid": "puid_0123456789012345678",
  "etag": "W/\"Gh/PcTdJD/AWHUhPW45kdw==\"",
  "displayName": "Example policy",
  "annotations": {
    "example-key": "example-value"
  },
  "createTime": "2024-01-02T15:01:23Z",
  "updateTime": "2024-01-02T15:01:23Z",
  "details": {
    "rules": [
      {
        "description": "Example principal access boundary policy rule",
        "resources": [
          "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

以下各部分介绍了主账号访问权限边界政策的元数据和详细信息中的字段。

元数据

主账号访问权限边界政策包含以下元数据：

  • name：主账号访问权限边界政策的名称。此名称的格式为 organizations/ORGANIZATION_ID/locations/global/principalAccessBoundaryPolicies/PAB_POLICY_ID，其中 ORGANIZATION_ID 是创建主账号访问权限边界政策的组织的数字 ID，PAB_POLICY_ID 是主账号访问权限边界政策的字母数字 ID。
  • uid：分配给主账号访问权限边界政策的唯一 ID。
  • etag：政策当前状态的标识符。您更新政策时，此值会发生变化。为防止更新发生冲突，etag 值必须与存储在 IAM 中的值匹配。如果 etag 值不匹配，则请求将会失败。
  • displayName：主账号访问权限边界政策的人类可读名称。
  • annotations：可选。用户定义的键值对列表。您可以使用这些注解为政策添加额外的元数据，例如，谁创建了该政策，或者该政策是否由自动化流水线部署。如需详细了解注解，请参阅注解。
  • createTime：Principal Access Boundary Policy 的创建时间。
  • updateTime：主账号访问边界政策的上次更新时间。

详情

每个主账号访问权限边界政策都包含一个 details 字段。此字段包含主账号访问边界规则和强制执行版本：

  • rules：主账号访问权限边界规则列表，用于定义受影响的主账号可以访问的资源。每个规则都包含以下字段：

    • description：规则的直观易懂的说明。

    • resources：您希望授权对象有权访问的 Resource Manager 资源（项目、文件夹和组织）列表。任何受此政策约束的主账号都有权访问这些资源。

      每个主账号访问权限边界政策在政策中的所有规则中最多可以引用 500 个资源。

    • effect：主账号与 resources 字段中列出的资源之间的关系。您可以在主账号访问权限边界规则中指定的唯一效果是 "ALLOW"。此关系使这些主账号有资格访问规则中列出的资源。

  • enforcementVersion：IAM 在强制执行政策时使用的强制执行版本。主账号访问权限边界政策版本决定了主账号访问权限边界政策可以阻止哪些权限。

    如需详细了解主账号访问权限边界政策版本，请参阅本页面上的主账号访问权限边界强制执行版本。

政策绑定的结构

Principal Access Boundary Policy 的政策绑定包含政策名称、要将政策绑定到的主账号的名称以及描述政策绑定的元数据。它还可以包含用于修改政策适用对象的确切主账号的条件。

例如，以下政策绑定将政策 example-policy 绑定到 ID 为 0123456789012 的 example.com 组织中的所有主账号。该政策绑定还包含一个条件，用于阻止对主账号 super-admin@example.com 强制执行政策。

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-policy-binding",
  "uid": "buid_01234567890123456789", 
  "etag": "W/\"cRMdDXbT82aLuZlvoL9Gqg==\"",
  "displayName": "Example policy binding",
  "annotations": {
    "example-key": "example-value"
  },
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "policyUid": "puid_0123456789012345678",
  "condition": {
    "title": "Exempt principal",
    "description": "Don't enforce the policy for super-admin@example.com",
    "expression": "principal.subject != 'super-admin@example.com'"
  },
  "createTime": "2024-01-02T17:00:16Z",
  "updateTime": "2024-01-02T17:00:16Z"
}

每个政策绑定都包含以下字段：

  • name：政策绑定的名称。此名称的格式为 RESOURCE_TYPE/RESOURCE_ID/locations/global/policyBindings/BINDING_ID，其中 RESOURCE_TYPE/RESOURCE_ID 是政策绑定的父资源的类型和 ID，BINDING_ID 是政策绑定的字母数字 ID。
  • uid：政策绑定所分配的唯一 ID。
  • etag：政策当前状态的标识符。您更新政策时，此值会发生变化。为防止更新发生冲突，etag 值必须与存储在 IAM 中的值匹配。如果 etag 值不匹配，则请求将会失败。
  • displayName：政策绑定的直观易懂的名称。
  • annotations：可选。用户定义的键值对列表。您可以使用这些注解为政策绑定添加额外的元数据，例如，政策绑定是由谁创建的，或者政策绑定是由自动化流水线部署的。如需详细了解注解，请参阅注解。

  • target：要将政策绑定到的主账号。该值的格式为 {"principalSet": PRINCIPAL_SET}，其中 PRINCIPAL_SET 是您要将政策绑定到的主账号集的 ID。

    每个目标最多可以有 10 项政策绑定到它。

  • policyKind：政策绑定引用的政策类型。对于主账号访问权限边界政策的政策绑定，此值始终为 PRINCIPAL_ACCESS_BOUNDARY。

  • policy：要绑定到目标主账号集的主账号访问权限边界政策。

  • policyUid：分配给 policy 字段中引用的主账号访问权限边界政策的唯一 ID。

  • condition：可选。影响 IAM 为哪些主账号强制执行政策的逻辑表达式。如果条件的评估结果为 true 或无法评估，Identity and Access Management 会针对发出请求的主账号强制执行政策。如果条件求值结果为 false，Identity and Access Management 不会针对主账号强制执行政策。如需了解详情，请参阅本页面上的主账号访问权限边界和条件。

  • createTime：政策绑定的创建时间。

  • updateTime：政策绑定上次更新的时间。

使用场景

以下是您可能想要使用主账号访问边界政策的常见场景，以及您可以在每种场景中创建的主账号访问边界政策和政策绑定示例。如需了解如何创建主账号访问边界政策并将其绑定到主账号集，请参阅创建和应用主账号访问边界政策。

将主账号限制为仅能访问贵组织中的资源

您可以使用主账号访问权限边界政策来确保组织中的主账号仅有权访问组织内的资源。

例如，假设您想确保组织 example.com 中的所有主账号仅有权访问 example.com 中的资源。example.com 中包含的主账号包括 example.com 域中的所有身份、example.com 中的所有员工身份池，以及 example.com 中任何项目中的所有服务账号和工作负载身份池。

您没有任何适用于贵组织中任何主账号的主账号访问权限边界政策。因此，所有主账号都有权访问所有资源。

如要让主账号无法访问 example.com 以外的资源，您可以创建一个主账号访问边界政策，让主账号有权访问 example.com 中的资源：

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "displayName": "Boundary for principals in example.org",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example.org",
        "resources": [
            "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

然后，您可以创建政策绑定，将此政策绑定到主账号集：

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only"
}

现在，example.com 中的所有主账号只能访问 example.com 中的资源。他们无法使用被主账号访问权限边界政策禁止的权限来访问 example.com 以外的资源，即使他们对这些资源拥有这些权限也是如此。

将服务账号限制为仅可访问单个项目中的资源

您可以使用主账号访问权限边界政策来确保特定项目中的服务账号只能访问该项目中的资源。

例如，假设您有一个项目 example-dev。您希望确保 example-dev 中的服务账号仅有权访问 example-dev 中的资源。

您有一项主账号访问权限边界政策，该政策使贵组织中的所有主账号（包括 example-dev 中的服务账号）都有权访问 example.com 中的资源。如需了解此类政策的具体形式，请参阅限制主账号对组织资源的访问。

如需使 example-dev 中的服务账号无法访问 example-dev 以外的资源，您需要先创建一个主账号访问边界政策，使主账号有权访问 example-dev 中的资源

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "displayName": "Boundary for principals in example-dev",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example-dev",
        "resources": [
          "//cloudresourcemanager.googleapis.com/projects/example-dev"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

然后，您可以创建政策绑定，将此政策绑定到 example-dev 中的所有主账号，并添加条件，以便政策绑定仅适用于服务账号：

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-dev-only-binding",
  "displayName": "Bind policy to all service accounts in example-dev",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/projects/example-dev"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "condition": {
    "title": "Only service accounts",
    "description": "Only enforce the policy if the principal in the request is a service account",
    "expression": "principal.type == 'iam.googleapis.com/ServiceAccount'"
  }
}

不过，此政策本身不会限制服务账号的资格。这是因为，现有的 Principal Access Boundary Policy 会让 example.com 中的所有主账号都有权访问 example.com 中的所有资源。主账号访问权限边界政策是叠加的，因此 example-dev 中的服务账号仍然有资格访问 example.com 中的所有资源。

为了确保 example-dev 中的服务账号仅有资格访问 example-dev 中的资源，您需要为现有主账号访问权限边界政策的政策绑定添加一个条件，以防止对 example-dev 中的服务账号强制执行该政策：

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "condition": {
    "title": "Exempt example-dev service accounts",
    "description": "Don't enforce the policy for service accounts in the example-dev project",
    "expression": "principal.type != 'iam.googleapis.com/ServiceAccount' || !principal.subject.endsWith('@example-dev.iam.gserviceaccount.com')"
  }
}

现在，example-dev 中的服务账号仅有权访问 example-dev 中的资源。他们无法使用被主账号访问权限边界政策阻止的权限来访问 example-dev 以外的资源，即使他们对这些资源具有这些权限也是如此。

后续步骤