Principal Access Boundary Policy

通过主账号访问权限边界 (PAB) 政策，您可以定义主账号可以访问的资源。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

应急关闭评估

主账号访问权限边界政策处于关闭状态。这意味着，如果 IAM 在评估主账号的访问权限时无法评估主账号访问权限边界政策，则 IAM 会阻止主账号访问该资源。

IAM 无法评估主账号访问权限边界政策的最常见原因是，主账号的详细信息仍在系统中传播。这种情况最有可能发生在新创建的用户身上。如需解决此问题，请让新主账号等待，稍后再尝试访问资源。

主账号访问权限边界政策阻止的权限

当主账号尝试访问它们没有资格访问的资源时，主账号访问权限边界政策会阻止其使用某些（但不是所有）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 作业截取快照。

主账号访问权限边界政策阻止的权限取决于主账号访问边界强制执行版本。

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

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

IAM 会定期添加新的主账号访问边界强制执行版本，以阻止其他权限。每个新版本还可以阻止上一个版本中的所有权限。

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

如需查看每个强制执行版本阻止的权限的完整列表，请参阅主账号访问权限边界政策阻止的权限。

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

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

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

您只能为现有的主账号访问权限边界政策创建绑定。如果尝试为已删除的主账号访问权限边界政策创建绑定，将会失败。如果您最近删除了主账号访问权限边界政策，有时可以成功创建绑定，但该绑定不会产生任何影响。IAM 会自动清理这些绑定。

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

支持的主账号

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

主账号集的类型
该类型主账号集中的主账号
此类型主账号集的 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/CUSTOMER_ID` 您可以通过以下方法查找客户 ID：使用 `gcloud organizations describe` 命令。您的工作区 ID 位于响应的 `directoryCustomerId` 字段中。使用 Cloud Resource Manager API 中的 `organizations.get` 方法。您的工作区 ID 位于响应的 `directoryCustomerId` 字段中。在管理控制台中查看您的客户 ID。此方法需要 Google Workspace 超级用户角色。	与 Google Workspace 网域关联的组织
项目主账号集	包含指定项目中的所有服务账号和工作负载身份池。格式：`//cloudresourcemanager.googleapis.com/projects/PROJECT_ID`	项目
文件夹的主账号集	包含指定文件夹中所有项目中的所有服务账号和所有工作负载身份池。格式：`//cloudresourcemanager.googleapis.com/folders/FOLDER_ID`	文件夹
组织的主账号集	包含以下身份：与您的 Google Workspace 客户 ID 相关联的所有网域中的所有身份贵组织中的所有员工身份池组织中任何项目中的所有服务账号和工作负载身份池格式：`//cloudresourcemanager.googleapis.com/organizations/ORGANIZATION_ID`	组织

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

您可以使用主账号访问权限边界政策的政策绑定中的条件表达式，进一步细化政策适用的主账号。

政策绑定的条件表达式由一个或多个通过最多 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'
```

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

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

在主账号访问权限边界政策绑定中使用条件的一种方式是减少单个主账号有资格访问的资源。

假设您有一个电子邮件地址为 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 主账号集中的其他主账号有资格访问的资源。

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

您确认，dev-project-service-account 受限的唯一主账号访问权限边界政策是使主账号有资格访问 example.com 中的所有资源的政策。
您可以创建新的主账号访问权限边界政策，使主账号有资格访问 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'"
}
```
您可以将 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'"
}
```
如需了解如何更新现有的主账号访问权限边界政策，请参阅修改主账号访问权限边界政策。

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

跨组织政策绑定

您无法为主账号访问权限边界政策创建跨组织政策绑定。跨组织政策绑定是指将一个组织中的政策绑定到另一个组织中的主账号集的政策绑定。

但是，将项目从一个组织迁移到另一个组织可能会导致跨组织政策绑定。

例如，请考虑以下情况：

您在组织 example.com 中有一个项目 example-project。
您希望 example-project 中的主账号有资格访问 example.com 中的资源。为此，您需要在 example.com 中创建一个主账号访问权限边界政策，让主账号有资格访问 example.com 中的资源，并将该政策绑定到 example-project 的主账号集中。
您将 example-project 从 example.com 移至 cymbalgroup.com。

即使 example-project 现在位于 cymbalgroup.com，项目的主账号集仍会绑定到 example-project 中的主账号访问权限边界政策。因此，项目主账号集中的主账号仍有资格访问 example-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 受约束的主账号访问权限边界政策。

例如，您可以修改 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
项目 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 会缓存可供公开读取的对象。

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

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

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

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

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

例如，以下主账号访问权限边界政策会让受政策约束的主账号有权访问组织中 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：主账号访问权限边界政策的创建时间。
updateTime：主账号访问权限边界政策的上次更新时间。

详细信息

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

rules：主账号访问边界规则列表，用于定义受影响的主账号有资格访问的资源。每个规则都包含以下字段：
- description：规则的直观易懂的说明。
- resources：您希望主账号有资格访问的 Resource Manager 资源（项目、文件夹和组织）的列表。任何受此政策约束的主账号都有权访问这些资源。
  
  每个主账号访问权限边界政策在其所有规则中最多可以引用 500 个资源。
- effect：主账号与 resources 字段中列出的资源之间的关系。您可以在主账号访问边界规则中指定的唯一效果是 "ALLOW"。此关系使这些主账号有资格访问规则中列出的资源。
enforcementVersion：IAM 在强制执行政策时使用的强制执行版本。主账号访问权限边界政策版本决定了主账号访问权限边界政策可以阻止哪些权限。

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

政策绑定的结构

主账号访问权限边界政策的政策绑定包含政策名称、要将政策绑定到的主账号集的名称以及描述政策绑定的元数据。它还可以包含用于修改政策适用对象的确切主账号的条件。

例如，以下政策绑定将政策 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 以外的资源的资格，您可以创建主账号访问权限边界政策，让主账号有资格访问 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.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'"
  }
}

不过，此政策本身不会更改服务账号有权访问的资源。这是因为，现有的主账号访问权限边界政策使 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 以外的资源，即使他们对这些资源拥有这些权限也是如此。

日后，如果您想增加这些服务账号有权访问的资源，可以向 example-dev-only 政策添加更多资源，也可以创建其他主账号访问权限边界政策并将其绑定到这些服务账号。

后续步骤

了解如何创建并应用主账号访问权限边界政策。
查看每个主账号访问权限边界政策强制执行版本阻止的权限。