本页面简要介绍了 Google Distributed Cloud (GDC) 网闸隔离配置中的项目网络政策。
项目网络政策定义了入站流量规则或出站流量规则。与 Kubernetes 网络政策不同，您只能为一项政策指定一种政策类型。政策中的每条规则都可以配置为“允许”（默认）或“拒绝”操作。
对于项目内的流量，GDC 会为每个项目应用预定义的项目网络政策，即默认项目内政策。
默认情况下，项目中的服务和工作负载与外部服务和工作负载隔离。不过，来自不同项目命名空间且位于同一组织内的服务和工作负载可以通过应用跨项目流量网络政策相互通信。
同样，将服务和工作负载连接到其他组织中项目外部的目标位置也需要明确批准。您必须停用数据渗漏防护，才能允许组织外部流量。
入站和出站防火墙规则是项目网络政策的主要组成部分，用于确定允许或拒绝哪些类型的流量进出您的网络。如需在 GDC 中为项目命名空间设置防火墙规则，请使用 GDC 控制台。
安全性和连接性
默认情况下，项目中的服务和工作负载会隔离在该项目中。如果不配置网络政策，它们将无法与外部服务和工作负载通信。
如需在 GDC 中为项目命名空间设置网络政策，请使用 ProjectNetworkPolicy 资源。借助此资源，您可以定义政策，以允许在项目内、项目之间、与外部 IP 地址之间以及从外部 IP 地址进行通信。此外，只有在为项目停用数据渗漏防护后，您才能从项目中转移工作负载。
GDC 项目网络政策可累加。对工作负载的最终强制执行是流量与应用于该工作负载的所有政策的并集进行任意匹配。如果存在多项政策，则每项政策的规则会累加组合，只要流量与其中至少一项规则匹配，就会被允许。
显式 Deny 规则绝对优先于 Allow 规则。如果流量流与 Deny 规则匹配，则会被丢弃，即使其他规则或默认平台政策允许该流量流也是如此。
此外，在您应用选择工作负载的单个政策后，您未指定的所有流量都会被拒绝（默认拒绝模式）。因此，当您应用一个或多个选择工作负载作为主体的政策时，系统仅允许明确允许（且未明确拒绝）的流量。
当您使用为项目分配的知名 IP 地址时，它会对来自组织的传出流量执行来源网络地址转换 (NAT)。
默认项目内政策
创建项目时，GDC 会自动在项目命名空间中创建一个名为 base-policy-allow-intra-project-traffic 的全局项目网络政策。此默认政策会执行以下操作：
- 选择项目中的所有用户工作负载作为其主体。
- 允许来自同一项目中所有工作负载的入站流量通过所有端口到达这些工作负载。
- 不允许来自其他项目或组织外部的入站流量。
GDC 仅在创建项目时创建默认政策一次。如果您更改或删除该政策，GDC 不会将其恢复。GDC 会将该政策作为名为 g-base-policy-allow-intra-project-traffic 的网络政策传播到项目中的每个集群。政策的 status.zones[].replicaStatus.propagatedName 字段会显示此名称。
如需查看默认政策，请运行以下命令：
kubectl --kubeconfig GLOBAL_API_SERVER get projectnetworkpolicy \
base-policy-allow-intra-project-traffic -n PROJECT -o yaml
替换以下内容：
GLOBAL_API_SERVER：全局 API 服务器的 kubeconfig 路径。如需了解详情，请参阅全球和可用区级 API 服务器。PROJECT：您的项目的名称。
如果该命令返回 NotFound 错误，则表示默认政策已被删除。如需重新添加，请参阅创建入站流量项目内政策。
默认政策会与您创建的政策合并，如下所示：
- 入站流量：无论是否存在默认政策，工作负载默认都会与其他项目以及组织外部隔离。您创建的入站流量政策会添加允许的来源，例如其他项目或外部 CIDR 块。由于默认政策存在，您无需在自己的入站流量政策中重复项目内规则。
- 工作负载级项目内入站流量：默认政策存在时，项目中的所有工作负载都可以在所有端口上相互访问。在您删除或更改默认政策之前，使用
Allow操作的工作负载级项目内入站流量政策不会限制此流量。为避免中断，请先应用工作负载级政策并验证它们是否已准备就绪，然后再删除默认政策。如需在保留默认政策的同时屏蔽特定的项目内流量，您可以使用显式拒绝规则（预览版功能）。如需了解详情，请参阅创建入站流量工作负载级项目内政策。 - 出站流量：默认情况下，项目没有出站流量政策。出站流量在组织内不受限制，但数据渗漏防护（默认启用）会阻止离开组织的流量。只有在您为项目停用数据渗漏防护后，出站流量政策才会生效。启用数据渗漏防护后，可用区级 API 服务器会拒绝出站流量政策，并且全局出站流量政策不会准备就绪。
全球项目网络政策
您可以创建全局项目网络政策。全球项目网络政策的范围涵盖整个 GDC 领域。每个 GDC 宇宙可以包含多个 GDC 可用区，这些可用区按区域进行组织，相互连接并共享一个控制平面。例如，一个包含两个区域（每个区域有三个可用区）的 Universe 可能如下所示：us-virginia1-a、us-virginia1-b、us-virginia1-c 和 eu-ams1-a、eu-ams1-b、eu-ams1-c。
可用区级项目网络政策的范围仅限于创建时指定的可用区。每个可用区都是一个独立的灾难域。可用区管理使用本地控制平面的基础设施、服务、API 和工具。
如需详细了解 GDC 领域中的全球资源，请参阅多可用区概览。
您可以使用网络 Kubernetes 资源模型 (KRM) API 创建全局项目网络政策。使用 API 版本 networking.global.gdc.goog 创建全球资源。
您可以使用 KRM API 或 GDC 控制台创建可用区级项目网络政策。使用 API 版本 networking.gdc.goog 创建可用区级资源。
“全部允许”网络政策
您可以创建“允许所有”网络政策，为项目建立广泛的默认访问规则。
您可以配置以下类型的“全部允许”网络政策：
- 允许所有流量的网络政策：允许来自任何来源（包括其他项目和外部 IP）的流量。
- 允许所有外部流量的网络政策：允许与组织外部 IP 地址之间的流量。
- 允许所有项目的网络政策：允许与组织内所有项目之间的流量。
如需了解详情，请参阅创建允许所有流量的网络政策。
显式拒绝网络政策
您可以在项目网络政策中配置明确的拒绝规则，以限制指定项目或 CIDR 块之间的连接。
拒绝规则的主要功能和限制：
- 优先级：拒绝规则绝对优先于允许规则（包括基本平台政策）。
- 出站流量安全规则：为防止意外屏蔽关键基础设施流量，出站流量拒绝规则会自动排除系统命名空间和非项目命名空间。
- 对等节点限制：为确保安全配置，入站流量拒绝规则必须在
from字段中明确指定来源对等节点，而出站流量拒绝规则必须在to字段中明确指定目标对等节点。您无法通过将对等字段留空来选择所有来源或目标。不允许将对等方字段留空，否则政策将被拒绝。 - 启用 DEP 时无法配置出站流量拒绝规则：为项目启用数据渗漏防护 (DEP) 后，您无法配置出站流量拒绝规则。
如需了解详情，请参阅创建显式拒绝网络政策。
工作负载级网络政策
您可以创建工作负载级网络政策，为项目中的各个虚拟机和 Pod 定义精细访问权限控制。这些政策就像工作负载的防火墙，可根据标签控制流量，从而增强安全性并隔离应用。这种精细度可让您更严格地控制哪些工作负载可以在项目内部和跨项目相互通信。
工作负载级网络政策还支持在单个可用区中强制执行 PNP。
如需了解详情，请参阅创建工作负载级项目内政策和创建工作负载级跨项目政策。
政策结构和验证
在 ProjectNetworkPolicy 资源中，工作负载标签选择器嵌套了多个层级。以下入站流量政策显示了每个选择器的正确位置：
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
namespace: PROJECT
name: allow-frontend-to-backend
spec:
policyType: Ingress
subject:
subjectType: UserWorkload
userWorkloadSelector:
labelSelector:
workloads:
matchLabels:
app: backend
ingress:
- from:
- projectSelector:
projects:
matchNames:
- PEER_PROJECT
workloadSelector:
labelSelector:
workloads:
matchLabels:
app: frontend
ports:
- protocol: TCP
port: 8080
替换以下内容：
PROJECT：您的项目的名称。PEER_PROJECT：包含客户端工作负载的项目的名称。
此政策允许 PEER_PROJECT 中标记为 app: frontend 的工作负载通过 TCP 端口 8080 连接到项目中标记为 app: backend 的工作负载。
编写政策时，请遵循以下规则：
- 始终将
spec.policyType明确设置为Ingress或Egress。Ingress政策只能包含具有from对等方的ingress规则，而Egress政策只能包含具有to对等方的egress规则。如果您省略policyType，则政策默认为Ingress，并且 API 服务器会拒绝仅包含egress规则的政策。 - 如需按标签选择主体工作负载，请使用
spec.subject.userWorkloadSelector.labelSelector.workloads。如果您省略userWorkloadSelector，则该政策将应用于项目中的所有用户工作负载。 - 请勿将标签选择器直接放在
spec.subject下。默认情况下，kubectl会拒绝spec.subject.matchLabels等字段，并显示strict decoding error: unknown field消息。 - 如需按标签选择对等工作负载，请在
from或to条目中使用projectSelector.workloadSelector.labelSelector.workloads。 - 如果主体或对等工作负载是虚拟机，请在其标签键前面加上
user-label.gpc.gke.io/。例如，使用user-label.gpc.gke.io/app: backend。 - 自动创建的默认项目内政策和一些现有政策使用已弃用的
spec.subject.workloadSelector字段，该字段直接采用标签选择器。在新政策中使用userWorkloadSelector。
如需在不应用政策的情况下针对全局 API 服务器验证政策，请运行服务器端试运行：
kubectl --kubeconfig GLOBAL_API_SERVER apply --dry-run=server \
--validate=strict -f POLICY_FILE
试运行会报告与实际 kubectl apply 命令相同的架构和验证错误，例如 Ingress 政策中的未知字段或 egress 规则，但不会创建或更改政策。试运行需要与应用政策相同的权限。试运行成功并不表示政策已强制执行。应用政策后，验证其是否已准备就绪。
如需列出全球 API 服务器接受的字段，请运行以下命令：
kubectl --kubeconfig GLOBAL_API_SERVER explain projectnetworkpolicy.spec \
--api-version=networking.global.gdc.goog/v1 --recursive
替换以下内容：
GLOBAL_API_SERVER：全局 API 服务器的 kubeconfig 路径。POLICY_FILE：ProjectNetworkPolicy清单的路径。
准备预定义角色和访问权限
如需配置项目网络政策，您必须拥有必要的身份和访问角色：
- Project Network Policy Admin：对全局项目命名空间中的所有多可用区项目网络政策资源拥有写入权限。请让您的 IAM 组织管理员为您授予
global-project-networkpolicy-admin角色。如需了解详情，请参阅预定义角色说明。
使用 IP 地址块定位集群节点
您可以使用 ProjectNetworkPolicy 资源中的 ipBlocks 字段来指定单个节点 IP 地址或节点 CIDR 范围，并控制 Pod 与特定集群节点之间的流量（例如，允许从控制平面节点到自定义网络钩子 Pod 的入站流量，或限制 Pod 到控制平面节点的出站流量）。如需了解相关说明，请参阅为标准集群创建项目内政策。
规模注意事项
在配置项目网络政策以定位特定节点或使用广泛的 CIDR 范围时，您的政策配置选择可能会影响可伸缩性和性能：
0.0.0.0/0的行为：在ipBlocks规则中使用广泛的 CIDR 范围（例如0.0.0.0/0）会匹配集群中的所有节点以及外部 IP 地址。- 扩缩：集群中的每个节点都会分配一个唯一的 CIDR 身份。每个工作负载端点（虚拟机或 Pod）都有一个存储其网络规则的内部政策表。在大型集群中，宽泛的
ipBlocks规则（例如0.0.0.0/0）会按节点数量比例增加政策表的使用量，因为系统必须为每个唯一的节点 CIDR 身份创建条目。 - 警告：如果您有大量节点或许多复杂政策，请避免在
ipBlocks规则中使用过于宽泛的 CIDR 范围，因为您可能会达到端点的政策表限制。如果端点达到此限制，则新的网络政策将无法应用，这可能会中断网络连接或阻止对该工作负载强制执行政策。