通过主账号访问边界 (PAB) 政策，您可以限制主账号可以访问的资源。
例如，您可以使用主账号访问边界政策来阻止主账号访问其他组织中的资源，这有助于防止钓鱼式攻击或数据渗漏。
如需了解 Identity and Access Management (IAM) 提供的其他类型的访问权限控制政策，请参阅政策类型。
主账号访问边界政策的工作原理
默认情况下，主账号有资格访问任何 Google Cloud 资源。这意味着，如果主账号对资源拥有某项权限且未被拒绝该权限，则可以使用该权限访问资源。
借助主账号访问边界政策，您可以限制主账号有资格访问的资源。如果主账号访问边界政策使主账号不符合访问某个资源的条件，则无论主账号被授予了什么角色，其对该资源的访问权限都会受到限制。
当主账号尝试访问它们没有资格访问的资源时，主账号访问边界政策可能会阻止其使用某些（但不是所有）Identity and Access Management (IAM) 权限。如需详细了解哪些权限会被屏蔽，请参阅主账号访问边界可以屏蔽的权限。
主账号访问边界政策由主账号访问边界规则组成。每条主账号访问边界规则都定义了一组受影响的主账号有资格访问的资源。您最多可以在组织中创建 1,000 项主账号访问边界政策。
创建主账号访问边界政策后，您需要创建政策绑定，以将该政策应用于一组主账号。
一个主账号可以受一项或多项主账号访问边界政策的约束。每个主账号只能访问这些政策中列出的资源。对于所有其他资源，主账号对该资源的访问权限将受到限制，即使您向该主账号授予该资源的角色也是如此。
由于主账号访问边界政策与主账号相关联，而不是与资源相关联，因此您可以使用这些政策来阻止主账号访问您不拥有的资源。例如，设想以下场景：
- 主账号 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 无法评估主账号访问边界政策，则会忽略主账号访问边界政策，并继续评估相关的允许和拒绝政策。
主账号访问边界政策阻止的权限
当主账号尝试访问它们没有资格访问的资源时，主账号访问边界政策会阻止其使用某些（但不是所有）Identity and Access Management (IAM) 权限来访问该资源。
如果主账号访问边界政策阻止某项权限，IAM 会针对该权限强制执行主账号访问边界政策。换言之，它会阻止任何没有资格访问资源的主账号使用该权限访问资源。
如果主账号访问边界政策不阻止某项权限，则主账号访问边界政策对主账号能否使用该权限没有任何影响。
例如，假设主账号 Lee (lee@example.com) 被授予 Dataflow 开发者角色 (roles/dataflow.developer)。此角色包含 dataflow.jobs.snapshot 权限，可让 Lee 对 Dataflow 作业进行快照。Lee 还受主账号访问边界政策的约束，因此无法访问 example.com 以外的资源。不过，如果主账号访问权限边界政策未屏蔽 dataflow.jobs.snapshot 权限，Lee 仍可在 example.com 以外的组织中为 Dataflow 作业截取快照。
主账号访问边界政策阻止的权限取决于主账号访问边界强制执行版本。
主账号访问边界强制执行版本
每个主账号访问边界政策都指定了一个强制执行版本，该版本用于标识主账号访问边界政策可以阻止的预定义 IAM 权限列表。您可以在创建或更新主账号访问权限边界政策时指定强制执行版本。如果您未指定强制执行版本，IAM 会使用最新的强制执行版本，并会在您更新该版本之前继续使用该版本。
IAM 会定期添加新的主账号访问边界强制执行版本，以阻止其他权限。每个新版本还可以阻止上一个版本中的所有权限。
如需在新的强制执行版本中屏蔽权限，您必须更新主账号访问权限边界政策，以使用新版本。如果您希望在有新版本发布时强制执行版本自动更新，则可以在创建政策时使用值 latest。不过，我们不建议使用此值，因为这可能会导致主账号意外失去对资源的访问权限。
如需查看每个强制执行版本阻止的权限的完整列表，请参阅主账号访问边界政策阻止的权限。
将主账号访问边界政策绑定到主账号集
如需将主账号访问边界政策绑定到主账号集，您需要创建一个政策绑定，其中指定要强制执行的主账号访问边界政策以及要针对哪个主账号集强制执行该政策。将政策绑定到主账号集中的主账号后，该主账号集中的主账号只能访问主账号访问边界政策规则中包含的资源。
您可以将主账号访问边界政策绑定到任意数量的主账号集。每个主账号集最多可以绑定 10 项主账号访问边界政策。
如需了解如何管理主账号访问边界政策，请参阅创建并应用主账号访问边界政策。
支持的主账号集
下表列出了您可以将主账号访问边界政策绑定到的正文集类型。每行都包含以下内容：
- 主账号集的类型
- 该类型主账号集中的主账号
- 相应类型的主账号集的 ID 格式
- 为该类型的主账号集提供父级政策绑定的 Resource Manager 资源（项目、文件夹或组织）
| 主账号集 | 详情 | 政策绑定的父级资源 |
|---|---|---|
| 员工身份池 |
包含指定员工身份池中的所有身份。
格式： |
包含员工身份池的组织 |
| 工作负载身份池 |
包含指定工作负载身份池中的所有身份。
格式： |
包含工作负载身份池的项目 |
| Google Workspace 网域 |
包含指定 Google Workspace 网域中的所有身份。
格式： 您可以使用以下方法查找工作区 ID：
|
与 Google Workspace 网域关联的组织 |
| 项目的主账号集 |
包含指定项目中的所有服务账号和工作负载身份池。
格式： |
项目 |
| 文件夹的主账号集 |
包含指定文件夹中的任何项目中的所有服务账号和所有工作负载身份池。
格式： |
文件夹 |
| 组织的主账号集 |
包含以下身份：
格式： |
组织 |
主账号访问边界政策的条件式政策绑定
您可以在主账号访问边界政策的政策绑定中使用条件表达式，以进一步细化该政策适用的主账号。
政策绑定的条件表达式由一个或多个通过最多 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 中的资源。
政策互动
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 - 项目
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"
}
}
以下各部分介绍了主账号访问边界政策的元数据和详情中的字段。
元数据
Principal Access Boundary Policy 包含以下元数据：
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 中的资源：
{
"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'"
}
}
不过，此政策本身不会限制服务账号的资格条件。这是因为，现有的主账号访问边界政策使 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 之外的资源，即使主账号对这些资源拥有相应权限也是如此。