本页列出了您在配置 VPC Service Controls 时可能会遇到的各种问题。
范围限定的政策出现意外行为
您可能会注意到,您的范围限定的政策允许一些意外的 VPC Service Controls 违规行为。如果您没有组织级层的访问权限政策,则范围限定的访问权限政策可能会遇到一些意外问题,这是一个已知问题。
如需解决此问题,请使用以下命令在组织级层创建访问权限政策:
gcloud access-context-manager policies create --organization <var>ORGANIZATION_ID</var> --title <var>POLICY_TITLE</var>
替换以下内容:
- ORGANIZATION_ID:组织 ID。
- POLICY_TITLE:人类可读的访问权限政策标题。
如需了解详情,请参阅创建访问权限政策。
共享 VPC
使用共享 VPC 时,包含属于共享 VPC 网络的项目的服务边界还必须包含托管该网络的项目。 当属于共享 VPC 网络的项目与宿主项目不在同一个边界内时,服务可能无法正常运行或可能被完全阻止。
确保共享 VPC 网络主机与连接到该网络的项目位于同一服务边界内。
无法添加 VPC 网络
在尝试将 VPC 网络添加到服务边界时,可能会出现以下错误:
ERROR: (gcloud.access-context-manager.perimeters.update) PERMISSION_DENIED: Permission 'compute.networks.get' denied on resource '//compute.googleapis.com/projects/PROJECT_NAME/global/networks/VPC_NETWORK_NAME' (or it may not exist)
发生此错误是由以下某种原因造成的:
- 该 VPC 网络不存在。
- VPC 网络已存在,但未配置任何子网。
- 调用方不具备所需权限。
如需解决此问题,请完成以下步骤:
通过查看项目中的网络,验证错误消息中指定的 VPC 网络是否存在。
在验证 VPC 网络之前,请完成以下步骤,确保在与 API 调用关联的项目中启用了 Compute Engine API:
在 Google Cloud 控制台中,前往 API 和服务页面。
前往“API 和服务”在 API 和服务页面上,验证 Compute Engine API 是否已列出。
如果缺少 Compute Engine API,请启用该 API。
启用该 API
检查调用方是否具有 VPC 网络的宿主项目的以下权限:
compute.networks.get。此权限可让您查看项目中的 VPC 网络。请拥有 VPC 网络宿主项目的组织的管理员向调用方授予在宿主项目上具有
compute.networks.get权限的 IAM 角色。例如,Compute Network Viewer 角色。如需详细了解如何授予角色,请参阅管理访问权限。
请务必阅读在服务边界中使用 VPC 网络时存在的限制。
边界之间的请求
通常情况下,访问权限级别用于允许从服务边界外请求边界内受保护资源的服务边界。
但是,系统将拒绝从一个边界中的项目请求另一个边界中的受保护资源,即使访问权限级别通常允许该请求也是如此。
例如,假设边界 1 内的项目 A 请求项目 B 内的资源。项目 B 内的资源受边界 2 保护。由于项目 A 在边界内,因此即使边界 2 的访问权限级别通常允许请求受保护的资源,该请求也会被拒绝。
可以通过以下方法之一支持边界之间的请求:
使用出站流量政策和入站流量政策。要允许从另一个边界向您的边界中的受保护资源发送请求,另一个边界必须使用出站流量政策,并且您必须在您的边界中设置入站政策。
使用边界网桥。 网桥允许不同边界内的两个或更多个项目向这些项目中的任何服务发出请求。即使这些服务受相应边界保护,也允许这些请求。
确保发出请求的服务和目标资源均不受边界的保护。在这种情况下,操作会成功,因为服务不会受到保护。
电子邮件地址无效或不存在
更新包含已删除主账号的边界时,您可能会遇到 The email address is invalid or non-existent 错误。
如需解决此问题,您必须从所有边界中移除无效的电子邮件地址:
导出所有边界。以下示例命令会以 YAML 格式导出服务边界列表:
gcloud access-context-manager perimeters list \ --policy=POLICY_NAME \ --format="json(name,title,description,perimeterType,status,spec,useExplicitDryRunSpec)" \ > my-perimeters.yaml
从
my-perimeters.yaml文件中移除无效的电子邮件地址并将其另存为my-perimeters-updated.yaml。
违反入站流量和出站流量规则
审核日志包含有关违反入站流量和出站流量规则的信息,可帮助您了解边界违规行为。
违反入站流量规则
违反入站流量规则表明边界外的 API 客户端尝试访问边界内的资源。由于没有匹配的入站流量规则或访问权限级别,因此服务边界会拒绝请求。
审核日志中的入站流量规则违规行为包含以下详细信息:
- 发生入站流量规则违规行为的边界的名称。
- 边界外的 API 客户端尝试访问的边界内资源。
在以下入站流量规则违规示例中,边界外的 API 客户端尝试访问边界 prod-perimeter 内的 Cloud Storage 存储桶 prod-protected-storage-bucket。
ingressViolations: [
0: {
targetResource: "projects/1234/buckets/prod-protected-storage-bucket"
servicePerimeter: "accessPolicies/123456789/servicePerimeters/prod-perimeter"
}
]
如需解决此问题,请为边界创建入站流量规则。如需详细了解入站流量规则,请参阅入站流量规则参考。
违反出站流量规则
审核日志中的出站流量规则违规行为表明发生了以下某个事件:
- 边界内的 API 客户端尝试访问边界外的资源。
- 涉及边界内资源以及边界外资源的 API 请求。例如,调用一条复制命令的 Cloud Storage 客户端,其中一个存储桶位于边界内,另一个存储桶位于边界外。
由于没有匹配的出站流量规则,因此服务边界会拒绝请求。审核日志中的出站流量规则违规行为包括以下详细信息:
- 来源类型,例如网络或资源。
- 边界遭遇出站流量违规行为的来源(资源或网络)。
- 遭遇出站流量违规行为的边界。
- 请求尝试访问的边界外的目标资源。
在以下出站流量规则违规示例中,API 请求包含来自边界 prod-perimeter 内的 projects/5678 的资源,以及来自边界外的 Cloud Storage 存储桶 external-storage-bucket 的对象。
egressViolations: [
0: {
sourceType: "Resource"
source: "projects/5678"
targetResource: "projects/4321/buckets/external-storage-bucket/objects/corp-resources.json"
servicePerimeter: "accessPolicies/123456789/servicePerimeters/prod-perimeter"
}
]
如需解决此问题,请为边界创建出站流量规则。如需详细了解出站流量规则,请参阅出站流量规则参考。
调试被 VPC Service Controls 阻止的请求
VPC Service Controls 审核日志是用于调试 VPC Service Controls 阻止的请求的主要工具。
如果访问被意外阻止,请参阅受服务边界保护的项目中的审核日志。这些日志包含有关所请求资源的重要数据以及请求遭拒的原因。如需了解如何诊断审核日志,请参阅访问违规分析器。
以下部分列出了您在使用 VPC Service Controls 时可能会遇到的 violationReason 值。
NETWORK_NOT_IN_SAME_SERVICE_PERIMETER
此问题可能是由以下某种原因造成的:
- 服务边界内的 VPC 网络中的客户端尝试访问不在同一边界内的项目。此请求会导致出站流量违规。如需解决此问题,请创建出站流量规则。
- 位于服务边界外的 VPC 网络中的客户端尝试访问受该服务边界保护的项目。此请求会导致入站流量违规。如需解决此问题,请创建入站流量规则。
客户端可能会从 Compute Engine 或 Google Kubernetes Engine 虚拟机发送请求,或者通过 Cloud Interconnect 或使用 VPC 网络配置的 VPN 从本地网络发送请求。
下图显示当服务边界内的 VPC 网络中的客户端尝试访问边界外的项目时发生出站流量违规:

以下是出站流量违规的示例:
egressViolations: [
{
servicePerimeter: "accessPolicies/<POLICY_NAME>/servicePerimeters/<PERIMETER_NAME>"
source: "projects/<NETWORK_PROJECT_NUMBER>"
sourceType: "Network"
targetResource: "projects/<RESOURCE_PROJECT_NUMBER>"
}
]
其中:
<POLICY_NAME>是访问权限政策的数字名称。<PERIMETER_NAME>是服务边界的名称。<NETWORK_PROJECT_NUMBER>是 VPC 网络所在的 Google Cloud 项目的编号。<RESOURCE_PROJECT_NUMBER>是资源所在的 Google Cloud 项目的编号。
下图显示当边界外的客户端尝试访问边界内的项目时发生入站流量违规:

以下是入站流量违规的示例:
ingressViolations: [
{
targetResource: "projects/<RESOURCE_PROJECT_NUMBER>",
source: "projects/<NETWORK_PROJECT_NUMBER>"
servicePerimeter: "accessPolicies/<POLICY_NAME>/servicePerimeters/<PERIMETER_NAME>"
}
]
其中:
<RESOURCE_PROJECT_NUMBER>是资源所在的 Google Cloud 项目的编号。<NETWORK_PROJECT_NUMBER>是 VPC 网络所在的 Google Cloud 项目的编号。<POLICY_NAME>是访问权限政策的数字名称。<PERIMETER_NAME>是服务边界的名称。
解决方法
如需解决此错误,请为边界