**发布时间:** 2025-11-07
**厂商:** AZURE
**类型:** TECH-BLOG
**原始链接:** https://techcommunity.microsoft.com/blog/azurenetworkingblog/layer-7-network-policies-for-aks-now-generally-available-for-production-security/4467598
---
<!-- AI_TASK_START: AI标题翻译 -->
[新产品/新功能] AKS 第 7 层网络策略现已正式可用,支持生产级安全与可观测性
<!-- AI_TASK_END: AI标题翻译 -->
<!-- AI_TASK_START: AI竞争分析 -->
# 产品功能分析
## 新功能/新产品概述
Azure Kubernetes Service (AKS) 的 **L7 网络策略 (Layer 7 Network Policies)** 功能现已正式发布 (GA),可用于生产环境。该功能旨在为在 AKS 上运行的容器化应用提供精细化的应用层网络安全与可观测性。
- **核心定义与目标**: 该功能允许用户基于应用层协议(如 HTTP)的属性(例如请求方法、URL 路径)来定义和强制执行网络访问控制规则。其核心目标是在云原生环境中实现 **零信任安全模型 (Zero Trust Security)**,遵循 **最小权限原则 (Principle of Least Privilege)**。
- **技术原理**: 该功能由开源项目 **Cilium** 和 Azure 的 **高级容器网络服务 (ACNS, Advanced Container Networking Services)** 提供支持。**Cilium** 利用 Linux 内核技术 **eBPF (Extended Berkeley Packet Filter)**,在内核层面直接对网络数据包进行高效的检查和过滤,从而在不引入传统 Sidecar 代理的情况下实现 L7 策略,具备高性能和低延迟的优势。
- **目标用户群与市场定位**: 主要面向对安全性和合规性有高要求的企业级 AKS 用户,特别是金融、零售和 SaaS 行业。目标用户包括平台工程师、DevOps 工程师和安全团队。该功能定位为 AKS 的原生、生产级网络安全增强解决方案。
## 关键客户价值
- **实现应用层零信任安全**
- 业务价值:超越了仅基于 IP 和端口的传统 L3/L4 网络策略,能够阻止应用漏洞被利用。例如,即使前端服务被攻破,也无法向后端库存 API 发送恶意的 `DELETE` 或 `POST` 请求,从而保护了核心业务逻辑和数据。
- 差异化优势:与依赖服务网格(如 Istio)实现 L7 策略的方案相比,基于 **Cilium** 和 **eBPF** 的方案性能开销更低。因为它直接在内核层面操作,无需为每个 Pod 注入 Sidecar 代理,从而简化了运维并减少了资源消耗。
- **增强出口流量控制与合规性**
- 业务价值:通过 **FQDN 过滤 (Fully Qualified Domain Name Filtering)** 功能,企业可以严格限制容器只能访问预先批准的外部域名(如 `*.example.com`)。这极大地降低了数据泄露和恶意软件回连的风险,是满足 PCI-DSS、GDPR 等合规性要求的重要技术手段。
- **简化集群级安全策略管理**
- 业务价值:通过 **CiliumClusterwideNetworkPolicy (CCNP)** 资源,管理员可以定义适用于整个集群或多个命名空间的统一安全策略。这简化了大规模集群的安全治理,减少了因策略配置不一致而导致的安全漏洞。
- **内置可观测性与快速故障排查**
- 业务价值:与 **Azure Managed Grafana** 的集成提供了对 L7 网络流量的可视化能力。当一个请求因策略被拒绝时,运维团队可以立即在仪表盘上看到被“Dropped”的流量,并能直接追溯到具体的策略规则,使安全事件审计和网络问题排查变得直观高效。
## 关键技术洞察
- **基于 Cilium 和 eBPF 的原生内核级实现**
- 技术独特性:_核心技术是 eBPF_。**eBPF** 允许在 Linux 内核中安全地运行自定义程序,无需修改内核源码。**Cilium** 利用此技术在网络数据路径的关键节点挂载 **eBPF** 程序,直接在内核中解析和处理 HTTP 等应用层协议,实现了高效的策略执行。
- 技术影响:
- **性能**:相比于基于用户空间代理(如 iptables 或 Sidecar)的传统方案,**eBPF** 的内核级处理路径更短,显著降低了网络延迟并提升了吞吐量。
- **安全性**:策略执行点位于内核,比用户空间的代理更难被容器内应用绕过或篡改,安全隔离性更强。
- **声明式 API 与 Kubernetes 原生集成**
- 技术创新点:通过 Kubernetes 自定义资源(CRD),如 `CiliumNetworkPolicy` 和 `CiliumClusterwideNetworkPolicy`,将复杂的网络安全能力以声明式、Kubernetes 原生的方式提供给用户。用户可以使用熟悉的 `kubectl` 和 GitOps 工作流来管理网络策略,无缝融入现有的云原生运维体系。
- 实现挑战:将 **Cilium** 的高级功能与 Azure 的托管控制平面(**ACNS**)深度集成,确保其在 AKS 环境中的稳定性、可扩展性和易用性,是该功能成功的关键。Azure 解决了版本管理、平滑升级以及与 Azure Monitor 等其他云服务的集成问题。
<!-- AI_TASK_END: AI竞争分析 -->
<!-- AI_TASK_START: AI全文翻译 -->
# AKS 的第 7 层网络策略:现已正式发布,为生产环境提供安全与可观测性!
**原始链接:** [https://techcommunity.microsoft.com/blog/azurenetworkingblog/layer-7-network-policies-for-aks-now-generally-available-for-production-security/4467598](https://techcommunity.microsoft.com/blog/azurenetworkingblog/layer-7-network-policies-for-aks-now-generally-available-for-production-security/4467598)
**发布时间:** 2025-11-07
**厂商:** AZURE
**类型:** TECH-BLOG
---
Azure 网络博客
# AKS 的第 7 层网络策略:现已正式发布,为生产环境提供安全与可观测性!
2025 年 11 月 08 日
我们很高兴地宣布,由 Cilium 和高级容器网络服务 (Advanced Container Networking Services, ACNS) 提供支持的 Azure Kubernetes 服务 (Azure Kubernetes Service, AKS) 的**第 7 层 (L7) 网络策略**已达到**正式发布 (General Availability, GA)** 状态!
从公共预览版到正式发布的这一历程标志着一个关键的进步:L7 网络策略现已获得全面支持、高度优化,并准备好应对您要求最严苛、任务最关键的生产工作负载。
---
## 一个实际案例:保护多层零售应用
让我们来看一个常见的生产场景。假设一个标准的零售应用程序在 AKS 上运行,包含三个核心的微服务 (microservices):
- `frontend-app`:处理用户流量并显示产品信息。
- `inventory-api`:一个后端服务,提供产品库存水平。它对前端应为只读。
- `payment-gateway`:一个处理交易的高度敏感的服务。它只应接受来自前端针对特定端点的 POST 请求。

**安全挑战:** 传统的 L4 策略会允许 `frontend-app` 在其端口上与 `inventory-api` 通信,但无法阻止一个被攻陷的 frontend Pod 试图通过发送 DELETE 或 POST 请求来利用潜在漏洞修改库存数据。
**L7 策略解决方案:** 借助正式发布的 L7 策略,您可以在应用层强制执行最小权限原则 (Principle of Least Privilege)。以下是保护 `inventory-api` 的方法:
```yaml
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: protect-inventory-api
spec:
endpointSelector:
matchLabels:
app: inventory-api
ingress:
- fromEndpoints:
- matchLabels:
app: frontend-app
toPorts:
- ports:
- port: "8080" # 应用程序端口
protocol: TCP
rules:
http:
- method: "GET" # 仅允许 GET 方法
path: "/api/inventory/.*" # 针对 /api/inventory/ 下的路径
```
### 结果:
- **允许:** 来自 `frontend-app` 的合法请求 (GET /api/inventory/item123) 会被无缝转发。
- **阻止:** 假设 `frontend-app` 被攻陷,任何源自它的恶意请求 (如 DELETE /api/inventory/item123) 都会在网络层被阻止。这种零信任 (Zero Trust) 方法保护了 `inventory-api` 服务免受威胁,无论源服务的安全状态如何。
同样的原则也可以应用于保护 `payment-gateway`,确保它只接受对 `/process-payment` 端点的 POST 请求,而不接受其他任何请求。
## 超越 L7:通过增强的安全性支持零信任
除了 L7 应用层策略以确保零信任外,我们还支持第 3/4 层网络安全和高级出站控制,如**完全限定域名 (Fully Qualified Domain Name, FQDN) 过滤**。
这种全面的方法允许管理员:
- **限制出站连接 (L3/L4 & FQDN):** 通过确保工作负载只能与经批准的外部服务通信来实施严格的出站控制。FQDN 过滤在这里至关重要,它允许 Pod 仅连接到受信任的外部域 (例如,www.trusted-partner.com),从而显著降低数据泄露的风险并保持合规性。要了解更多信息,请访问 [FQDN 过滤概述](https://learn.microsoft.com/en-us/azure/aks/container-network-security-fqdn-filtering-concepts) 。
- **在整个集群中强制执行统一策略 (CCNP):** 将保护范围扩展到单个命名空间 (namespace) 之外。通过将安全措施定义为 Cilium 集群级网络策略 (Cilium Clusterwide Network Policy, CCNP),得益于其正式发布 (GA),管理员可以确保在多个命名空间或整个 Kubernetes 集群中统一执行策略,从而简化管理并加强所有工作负载的整体安全态势。
## CCNP 示例:带有 FQDN 过滤的 L4 出站策略
此策略确保集群中的**所有 Pod** (CiliumClusterwideNetworkPolicy) **仅被允许**在标准 Web 端口 (80 和 443) 上建立到 `*.example.com` 域的出站连接。
```yaml
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
name: allow-egress-to-example-com
spec:
endpointSelector: {} # 应用于集群中的所有 Pod
egress:
- toFQDNs:
- matchPattern: "*.example.com" # 允许访问 example.com 的任何子域
toPorts:
- ports:
- port: "443"
protocol: TCP
- port: "80"
protocol: TCP
```
---
## 卓越运营:值得信赖的可观测性
一个安全的系统必须是可观测的。随着正式发布,您对 L7 流量的集成可见性已为生产环境准备就绪。
在我们上面的例子中,被阻止的 DELETE 请求并非无声无息。它会立即在您的 Azure Managed Grafana 仪表盘中显示为一个 **“Dropped”** (丢弃) 的流量,并直接归因于 `protect-inventory-api` 策略。这使得安全事件可审计且易于诊断,使运营团队能够实时检测到配置错误或威胁。以下是一个示例仪表盘布局截图。

---
## 后续步骤:升级并保护您的生产环境!
我们鼓励您在 AKS 集群上启用 L7 网络策略,并提升容器化工作负载的网络安全控制水平。在我们继续开发和改进此功能的过程中,我们珍视您的反馈。请参阅 [第 7 层策略概述](https://aka.ms/acns/l7policy) 获取更多信息,并访问 [如何应用 L7 策略](https://aka.ms/acns/l7policy-how-to) 查看示例场景。
更新于 2025 年 11 月 07 日
版本 1.0
<!-- AI_TASK_END: AI全文翻译 -->