Azure Kubernetes 服务 (AKS)网络安全最佳做法

默认情况下，Kubernetes 作为一个平面网络运行，其中所有 Pod 可以相互自由通信。 这种不受限制的连接对于开发人员来说可能很方便，但在应用程序规模化时会带来重大安全风险。 假设一个组织部署了多个微服务，每个微服务都处理敏感数据、客户事务或后端作。 没有任何限制，任何泄露的 Pod 都可以访问未经授权的数据或中断服务。

生产环境中的网络安全需要针对工作负载通信和端点暴露采取控制措施。 使用 Kubernetes 网络策略 来限制工作负载之间的流量，选择最不公开的 Kubernetes 服务类型，以满足每个应用程序的要求，并限制对 Kubernetes API 服务器的访问。

规划服务和群集公开

从私有访问开始，仅在工作负载需要时才开放公网访问。 网络策略补充，但不替换 Kubernetes 服务、入口控件、Web 应用程序防火墙（WAF）或 API 服务器访问控制。

规划生产 AKS 群集时，请参考以下指导：

仅在群集内使用的服务

建议：使用 ClusterIP 服务，即默认服务类型。

应用入口和出口网络策略，以便只有经过授权的 Pod 和命名空间才能访问服务的后盾 Pod。

从专用网络访问的服务

建议：使用 内部 LoadBalancer 服务 或内部入口控制器。

专用 IP 限制对已连接到虚拟网络的网络的访问。 还可以使用网络安全组、防火墙和网络策略限制源网络。

公共非 HTTP 或非 HTTPS 服务

建议：仅在需要直接外部访问时使用公共服务 LoadBalancer 。

限制允许的源 IP 范围，仅开放所需的端口，并避免将 NodePort 用作直接暴露生产环境的方式。

公共 HTTP 或 HTTPS 应用程序

建议：将服务置于 入口控制器 或网关 API 实现的后面，而不是将公共 IP 分配给每个服务。

集中 TLS 终止、路由、身份验证和公共 IP 管理。 将后端服务配置为 ClusterIP 不需要直接外部访问时。

面向 Internet 的 Web 应用程序和 API

建议：将Azure Web 应用程序防火墙（WAF）放在入口层的前面，例如容器Azure 应用程序网关。

使用托管和自定义 WAF 规则来帮助防范常见的 Web 攻击。 限制对入口源的直接访问，以便客户端无法绕过 WAF。

Kubernetes API 服务器

建议：当管理员和自动化可以通过专用网络进行连接时，首选 专用 AKS 群集 。

专用群集将 API 服务器流量保留在专用终结点上。 规划 DNS、VPN、ExpressRoute、对等互连或安全的管理主机，以便进行管理访问。

公共 Kubernetes API 服务器

建议：如果需要公共终结点，请配置 API 服务器授权 IP 范围并使用具有最低特权 RBAC 的Microsoft Entra ID。

仅允许已知的管理和自动化源范围。 不要让 API 服务器对所有源 IP 地址保持打开状态。

在部署之前，梳理每个入站访问路径，并记录其必须是仅限集群内部、仅对已连接网络开放，还是公开的。 避免使用会绕过经批准入口和 WAF 层的对外公开并行访问路径。 为有文档说明需通过互联网访问的终结点预留公共 IP 地址，并定期审查公共 LoadBalancer、入口和 API 服务器终结点，以确认是否仍有必要。

什么是 Kubernetes 网络策略？

Kubernetes 网络策略是一组规则，用于控制 Pod 如何相互通信和与外部服务通信。 它提供对网络流量的精细控制，使管理员能够在命名空间级别强制实施安全性和分段。 通过实施网络策略，可以获得：

• 更强大的安全态势：防止群集内未经授权的横向移动。
• 合规性和治理：通过控制通信路径来强制实施法规要求。
• 减少爆破半径：通过限制其网络访问来限制受损工作负荷的影响。

网络策略最初工作在 OSI 模型的第 3 层（IP）和第 4 层（TCP/UDP），从而能够对 Pod 间通信和外部通信进行基本控制。 高级网络策略引擎（如 Cilium）将策略强制实施扩展到第 7 层（应用程序层），从而更深入地控制新式云原生应用程序的应用程序流量。

网络策略是命名空间范围的，这意味着每个策略都适用于特定命名空间中的工作负荷。 网络策略的主要组件包括：

• Pod 选择器：定义策略根据标签应用的 Pod。
• 入口规则：指定允许的传入连接。
• 出口规则：指定允许的传出连接。
• 策略类型：定义策略是适用于入口（传入）、出口（传出）还是两者。

构建有效网络策略的基础

在编写配置之前，有效的网络策略需要了解应用程序体系结构、流量模式和安全要求。

了解负载连接性

在实施网络策略之前，需要了解工作负载如何相互通信和外部服务。 此步骤可确保策略不会无意中阻止关键流量，同时有效限制不必要的暴露。

• 使用可见性工具：除了应用程序团队提供的网络要求外，还使用 Cilium Hubble 和 Retina 等工具分析 Pod 到 Pod 流量，确定哪些服务必须通信，并定义其入口和出口依赖项。 例如，前端可能需要访问后端 API，但不应直接与数据库通信。

• 在网络策略中使用标签：传统上，网络安全策略依赖于静态 IP 地址来定义流量规则。 此方法在 Kubernetes 中存在问题，因为 Pod 是临时的-经常创建和销毁，通常使用动态分配的 IP 地址。 根据不断变化的 IP 维护安全规则需要持续更新，使策略管理效率低下且容易出错。

标签通过提供一种稳定的方式来对工作负荷进行分组来解决这一难题。 Kubernetes 网络策略使用标签来定义在 Pod 重启或跨节点移动时保持一致的安全规则，而不是依赖于固定 IP。 例如，策略可以允许在标记app: frontendapp: backend的 Pod 之间进行通信，并确保流量按预期方式流动，而不考虑 Pod IP 更改。 此基于标签的方法对于在云原生环境中实现可缩放的意向驱动的网络安全至关重要。

定义完善的标记策略简化了策略管理，减少了配置错误，并增强了跨群集的安全强制。

• 定义微分类：将工作负荷组织到安全区域（例如前端、后端和数据库区域）有助于强制实施最低特权原则。 例如，将处理客户事务的微服务与常规用途应用程序隔离开来。

Kubernetes 的分层安全方法

仅依赖于基本 Kubernetes 网络策略可能不足以满足所有安全需求。 分层方法可确保跨不同级别的网络通信提供全面的保护。

• L3/L4 策略：控制基于 IP、端口和协议级别的 Pod 标签和命名空间的流量。
• 基于 FQDN 的策略：将出口流量限制到特定的外部域，确保工作负荷只能访问批准的外部服务（例如：仅允许访问 API 调用 microsoft.com ）。
• 第 7 层策略：根据 HTTP 方法、标头和路径筛选请求，以保护 API 并强制实施应用程序层安全策略。

管理网络策略

管理网络策略的团队取决于组织的结构和安全要求。 平衡的方法使安全团队和应用程序开发人员能够有效地协作。

• 集中式安全管理：安全或网络团队应定义基线策略，以强制实施全局安全要求，例如默认拒绝所有规则或合规性驱动的限制。
• 开发人员通过防护措施实现自主性：应用程序团队应该能够在命名空间中定义特定于服务的网络策略，从而在保持灵活性的同时实现安全性。
• 策略生命周期管理：定期审查和更新策略可确保安全性与不断发展的应用程序体系结构保持一致。 可观测性工具可以帮助检测策略配置错误和缺少规则。

示例：使用网络策略保护多层 Web 应用程序

步骤 1：了解工作负荷连接

使用 Cilium Hubble 观察 Pod 的通信方式。

梳理所需的连接关系：

步骤 2：应用用于实施策略的标签

通过正确标记工作负载，即使 Pod IP 发生更改，策略也能保持稳定。

• 用于 UI Pod 的 app: frontend。
• 用于 API Pod 的 app: backend。
• 用于 DB Pod 的 app: database。

步骤 3：实现应用程序级网络策略

此示例使用两层网络策略：L3/L4 策略来控制微服务与完全限定的域名（FQDN）策略之间的流量，以控制流向外部支付网关的出口流量。

允许前端流量访问后端

应用出口和入口策略，以便前端 Pod 只能在 TCP 端口 8080 上访问后端 Pod。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-egress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: backend
      ports:
        - protocol: TCP
          port: 8080
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-ingress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

允许后端流量访问数据库

应用出口和入口策略，以便后端 Pod 只能在 TCP 端口 5432 上访问数据库 Pod。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-egress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: database
      ports:
        - protocol: TCP
          port: 5432
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-ingress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: backend
      ports:
        - protocol: TCP
          port: 5432

允许后端流量流向外部支付 API

应用 Cilium 网络策略，以便后端 Pod 只能在 TCP 端口 443 上解析和连接到 payments.example.com 。

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: backend-payment-api
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: backend
  egress:
    - toEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": kube-system
            "k8s:k8s-app": kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: ANY
          rules:
            dns:
              - matchName: payments.example.com
    - toFQDNs:
        - matchName: payments.example.com
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP

步骤 4：管理和维护策略

下表总结了团队应在群集之间强制执行的策略层。

确保应用程序网络策略符合基线、平台和安全要求，同时允许所需的工作负荷通信。

由 Cilium 提供支持的 Azure CNI

Azure 由 Cilium 提供支持的容器网络接口（CNI）使用 eBPF（扩展的 Berkeley 数据包筛选器）为 Kubernetes 工作负载提供高性能网络、可观测性和安全性。 与传统依赖于基于 iptables 的数据包筛选的传统 CNI 不同，由 Cilium 提供支持的 Azure CNI 使用 eBPF 在内核级别运行，从而实现高效且可缩放的网络策略强制实施。 Cilium 是适用于 Azure Kubernetes 服务 (AKS) 上的 Linux 工作负荷的建议网络策略引擎。 有关其他受支持的引擎及其平台支持的详细信息，请参阅 AKS 中的网络策略选项。 Azure Kubernetes 服务将 Cilium 集成为托管组件，简化了网络安全强制实施。 管理员可以直接在其 AKS 群集中定义 CiliumNetworkPolicy 资源，而无需外部控制器。

Cilium 身份将基于标签的策略强制执行扩展到身份层面。 Pod 频繁变动的大型集群可能会遇到可扩展性问题，因为节点必须不断更新 IP 过滤规则。 Cilium 标识映射到标签，并允许在标识解析后立即启动连接，而无需等待每个节点上的筛选器更新。

使用由 Cilium 提供支持的 Azure CNI，无需安装单独的网络策略引擎，例如Azure网络策略管理器或 Calico。

创建使用由 Cilium 提供支持的 Azure CNI 的 AKS 群集

以下示例创建了一个由 Cilium 提供支持的 Azure CNI Overlay AKS 群集。 --network-plugin-mode overlay选项用于配置 Azure CNI Overlay 网络，--pod-cidr 192.168.0.0/16用于分配 Pod IP 地址范围，而 --network-dataplane cilium则用于选择 Cilium 作为数据平面。 群集创建选项和地址值对于其他 AKS 网络配置可能有所不同。 使用适合网络配置的值。

az aks create \
  --name <clusterName> \
  --resource-group <resourceGroupName> \
  --location <location> \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --pod-cidr 192.168.0.0/16 \
  --network-dataplane cilium \
  --generate-ssh-keys

Cilium 网络策略资源和组件

借助由 Cilium 提供支持的 Azure CNI，可以使用两种可用格式在 Kubernetes 中本机配置网络策略：

• 支持在 Pod 的入口或出口处实施 L3 和 L4 策略的标准 NetworkPolicy 资源。
• 扩展 CiliumNetworkPolicy 格式，它可用作 CustomResourceDefinition，它支持在第 3-7 层针对入口和出口制定策略。

使用这些自定义资源定义（CRD）来定义安全策略。 Kubernetes 会自动将策略分发到群集中的所有节点。

网络策略由几个关键组件组成：

• Pod 选择器：使用标签指定策略应用到的 Pod。

• 策略类型：确定策略适用于入口（传入流量）、出口（传出流量）还是两者。

• 入口规则：定义允许的源（Pod、命名空间或 IP 范围）和端口。

• 出口规则：定义允许的目标和端口。

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: frontend-egress
    namespace: default
  spec:
    podSelector:
      matchLabels:
        app: frontend
    policyTypes:
      - Egress
    egress:
      - to:
          - podSelector:
              matchLabels:
                app: backend
        ports:
          - protocol: TCP
            port: 8080
  

使用 ACNS 的高级网络策略

Azure Kubernetes 服务提供高级容器网络服务（ACNS），这是一套旨在增强 AKS 群集网络功能的服务。

ACNS 的主要功能是容器网络安全，它提供高级安全功能来保护容器化工作负荷。 这些功能包括完全限定的域名（FQDN）筛选和第 7 层 （L7） 策略，用于精细控制出口流量和应用程序层通信。

容器网络安全是一项面向 Linux 节点池的付费功能，要求使用由 Cilium 提供支持的 Azure CNI，且 Kubernetes 版本为 1.29 或更高版本。

使用 FQDN 筛选保护出口流量

传统上，Kubernetes 网络策略基于 IP 地址。 在 Pod IP 频繁更改的动态环境中，这些策略可能难以管理。 使用 FQDN 筛选 ，可以使用域名而不是 IP 地址来定义策略，从而简化了流量控制。

FQDN 筛选需要 AKS 群集，该群集使用由 Cilium 提供支持的 Azure CNI，运行 Kubernetes 1.29 或更高版本，并且已启用 ACNS。 配置一个 CiliumNetworkPolicy，以定义所选 Pod 可访问的域。

若要在Azure Kubernetes 服务 (AKS)中启用高级容器网络服务（ACNS），请使用标志--enable-acns。

示例：在现有群集上启用高级容器网络服务

az aks update \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --enable-acns

此命令在使用 Cilium 数据平面的现有群集上启用 ACNS（包括 FQDN 筛选）。

示例：生成允许流量传入 bing.com 及其子域的网络策略

以下策略允许选定的 Pod 解析并连接到 bing.com 及其子域名。 规则 dns 允许名称解析，规则 toFQDNs 允许与解析的地址建立出口连接。

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "allow-bing-fqdn"
spec:
  endpointSelector:
    matchLabels:
      app: demo-container
  egress:
    - toEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": kube-system
            "k8s:k8s-app": kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: ANY
          rules:
            dns:
              - matchName: "bing.com"
              - matchPattern: "*.bing.com"
    - toFQDNs:
        - matchName: "bing.com"
        - matchPattern: "*.bing.com"

使用 L7 策略保护 API 的安全性

AKS 中的第 7 层 （L7） 策略使用 CiliumNetworkPolicy 资源按 HTTP 方法和路径、gRPC 路径和 Kafka 主题等属性筛选应用程序流量。 他们需要 AKS 群集上的 ACNS，该群集使用由 Cilium 提供支持的 Azure CNI。 标准网络策略控制第 3 层（IP）和第 4 层（TCP/UDP）的流量，但不检查这些应用程序级属性。

第 7 层 （L7） 策略提供以下优势和功能：

• 精细 API 安全性：基于 HTTP、gRPC 或 Kafka 请求数据（而不仅仅是 IP 地址和端口）强制实施策略。
• 减少攻击面：通过筛选应用程序层上的流量来防止未经授权的访问并缓解基于 API 的攻击。
• 合规性和审核：通过记录和控制特定的 API 交互来确保遵守安全标准。
• 简化策略管理：通过内置的、由 Cilium 提供支持的 L7 控制功能，避免部署额外 Sidecar 代理所带来的运维负担。

L7 策略支持 HTTP、HTTPS、gRPC 和 Kafka 协议。

示例：在现有群集上启用 ACNS 和 L7 策略

az aks update \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --enable-acns \
  --acns-advanced-networkpolicies L7

此命令在现有群集上启用 ACNS 和 L7 策略强制实施。 --acns-advanced-networkpolicies设置为L7还启用 FQDN 筛选。

示例：仅允许从前端 Pod 到端口 8080 上后端服务的对 /api 的 GET 请求

以下策略允许所选前端 Pod 仅 GET 向 /api 所选后端终结点的 TCP 端口 8080 发送请求。

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: frontend-l7-policy
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: frontend
  egress:
    - toEndpoints:
        - matchLabels:
            app: backend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/api"

AKS 工作负载的网络策略

以下策略有助于在 AKS 工作负载之间强制执行最小权限流量规则。

采用零信任模型

默认情况下，Kubernetes 允许群集中的所有 Pod 之间不受限制的通信。 零信任方法要求你默认拒绝流量，并显式允许所需的通信路径。 默认的拒绝所有网络策略可确保只有必要的流量在工作负荷之间流动。

拒绝所有策略的示例：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: default
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

命名空间和多租户分段

在多租户环境中，命名空间有助于隔离工作负荷。 不同的团队通常在专用命名空间中管理其应用程序，确保工作负荷之间的逻辑隔离。 当多个应用程序彼此一起运行时，这种分离至关重要。 在命名空间范围内应用网络策略通常是保护工作负荷的第一步，因为它可以防止不同团队管理的应用程序之间的不受限制的横向移动。

例如，将所有入口流量限制为命名空间，只允许来自同一命名空间的流量：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-cross-namespace
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: team-a

工作负载隔离的微分段

虽然基于命名空间的分段是保护多租户 Kubernetes 群集的重要第一步，但应用程序级微分类可以精细控制命名空间中工作负荷的交互方式。 单独进行命名空间隔离不会阻止同一命名空间中不同应用程序之间的意外或未经授权的通信。 这就是 Pod 级别的分段变得至关重要的地方。

例如，如果前端服务只应与同一命名空间中的后端服务通信，则使用 Pod 标签的策略可以强制实施此限制：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-to-backend
  namespace: team-a
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: backend
      ports:
        - protocol: TCP
          port: 8080

这可以防止前端 Pod 与其他服务建立意外的连接，从而降低命名空间内未经授权的访问或横向移动的风险。

通过将命名空间范围的隔离与精细的应用程序级策略相结合，团队可以实施多层安全模型，从而防止未经授权的流量，同时允许应用程序功能的必要通信。

分层安全方法

网络安全应在层中实现，结合多个强制级别：

• L3/L4 策略：限制 IP 和端口级别的流量（例如：允许端口 443 上的 TCP 流量）。
• 基于 FQDN 的筛选：基于域名而不是 IP 地址限制外部通信。
• L7 策略：基于应用程序层属性控制通信（例如：仅允许对特定 API 路径的 HTTP GET 请求）。

例如，Cilium L7 策略可以限制前端服务仅向后端 API 发出 GET 请求：

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: frontend-l7-policy
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: frontend
  egress:
    - toEndpoints:
        - matchLabels:
            app: backend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/api"

这可以防止前端发出 POST 或 DELETE 请求，从而限制攻击面。

将 RBAC 与网络策略管理集成

基于角色的访问控制（RBAC）在确保只有经过授权的用户或团队才能创建、修改或删除网络策略方面发挥关键作用。 如果没有适当的访问控制，配置错误的策略可能会向未经授权的访问公开工作负荷，或无意中阻止关键应用程序流量。

通过将 Kubernetes RBAC 与网络策略结合使用，组织可以强制在平台管理员、安全团队和应用程序开发人员之间实现职责分离。 典型的方法是：

• 通过平台或安全团队定义基线安全策略，以强制实施合规性并限制外部访问。
• 授予应用程序团队仅针对其各自的命名空间创建或更新网络策略的限制权限。

例如，以下 RBAC 策略允许开发人员创建和修改网络策略，但仅在分配的命名空间内：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: network-policy-editor
  namespace: team-a
rules:
  - apiGroups: ["networking.k8s.io"]
    resources: ["networkpolicies"]
    verbs: ["get", "list", "create", "update", "delete"]

使用以下方法 RoleBinding将此角色绑定到特定团队：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-a-network-policy-binding
  namespace: team-a
subjects:
  - kind: User
    name: developer@example.com
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: network-policy-editor
  apiGroup: rbac.authorization.k8s.io

通过将网络策略修改限制为指定的团队和命名空间，组织可以防止意外配置错误或未经授权的更改，同时仍允许开发人员灵活地实施特定于应用程序的安全策略。

此方法强化了最低特权原则，同时确保网络分段策略保持一致、安全且符合组织策略。

旧版和第三方解决方案

Azure 网络策略管理器 （NPM）

Azure 网络策略管理器（NPM）是用于在 AKS 上强制实施 Kubernetes 网络策略的旧解决方案。

对于 Linux 节点，Microsoft建议从 NPM 过渡到 Cilium，从而通过基于 eBPF 的强制实施提供更好的性能、可伸缩性和增强安全性。 有关迁移指南，请参阅从Azure网络策略管理器升级到 Cilium。

NetworkPolicy对Windows节点的支持

由 Cilium 提供支持的 Azure CNI 仅支持 Linux 节点。 对于Windows工作负载，AKS 支持集成到 AKS 中以简化部署的 Calico。 可以在创建群集时使用 --network-policy calico 标志启用它。 NPM 还将继续支持 Windows 节点，直至 2026 年 9 月 30 日，但新订阅已无法再启用启用该支持所需的功能标志。

Calico 开放源代码：第三方解决方案

Calico 开放源代码是一种第三方解决方案，用于在 Linux 和Windows节点上强制实施 Kubernetes 网络策略。 Tigera 维护卡利科项目和图像。 Microsoft支持仅限于确保 Calico 与 AKS 集成，并在平台内按预期运行。 将超出 AKS 集成范围的上游缺陷、功能请求和故障排查问题提交给 Calico 开源社区或 Tigera。

对于 Linux 节点，Microsoft建议使用 Cilium 执行网络策略。 对于Windows节点，Microsoft建议使用 Calico。

结论

网络策略是 Kubernetes 安全性的基本组成部分，使组织能够控制流量流、强制实施工作负荷隔离并减少攻击面。 随着云原生环境的发展，仅依赖于基本第 3/4 层策略已经不够了。 高级解决方案（如第 7 层筛选和基于 FQDN 的策略）提供保护新式应用程序所需的精细安全性和灵活性。

通过遵循零信任模型和微分段等做法，并通过采用由 Cilium 提供支持的 Azure CNI，团队可以增强安全性，同时保持运营效率。 随着 Kubernetes 网络的发展，现代可观测性驱动方法有助于保护工作负载。