【零信任安全架构】微分段深度拆解：从 VLAN 到 eBPF 的访问控制演化

微分段（Microsegmentation）是将网络划分为细粒度的安全区域，每个区域独立执行访问控制策略。与传统 VLAN 的”同一 VLAN 内任意通行”不同，微分段可以精确到单个工作负载级别——只允许 order-service 访问 payment-service 的 POST /charge 端点。

前置阅读：身份感知代理、零信任策略引擎。

一、四层微分段技术栈

flowchart TD
    L1["L2: VLAN / VXLAN<br/>广播域隔离<br/>同 VLAN 内全通"]
    L2["L3/L4: ACL / Security Group<br/>IP + 端口过滤<br/>无法处理 IP 重用"]
    L3["L3/L4 + Label: K8s NetworkPolicy<br/>Pod label selector<br/>不依赖 IP 地址"]
    L4["L7 + Identity: Cilium / Istio<br/>基于身份的 HTTP/gRPC/Kafka<br/>级别控制"]

    L1 --> L2 --> L3 --> L4

1.1 L2: VLAN 隔离

VLAN（虚拟局域网）将物理网络划分为多个逻辑隔离的广播域。它的安全模型很简单：不同 VLAN 之间必须通过路由器或防火墙才能通信，路由器上的 ACL 控制哪些 VLAN 可以访问哪些端口。

局限性：同一 VLAN 内的所有设备被视为具有相同的信任级别——如果 payment-VLAN 中有 5 个服务，它们可以互相随意访问。攻击者只需攻破其中任何一个就能横向移动到其余 4 个。

1.2 L3/L4: ACL 和安全组

AWS Security Group、GCP Firewall Rule、iptables 规则都属于这一层——通过 IP 地址和端口号进行访问控制。

# 只允许来自 10.0.1.0/24 的流量访问 5432 端口（PostgreSQL）
iptables -A INPUT -p tcp --dport 5432 -s 10.0.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 5432 -j DROP

这层的核心缺陷是依赖 IP 地址——而 IP 在容器环境中是短暂的。当 Pod 重建时 IP 会变化，安全组规则必须随之更新——这个更新窗口就是攻击窗口。

1.3 Kubernetes NetworkPolicy

NetworkPolicy 将匹配条件从 IP 迁移到 label selector——策略基于 Pod 的标签匹配，不依赖具体的 IP 地址：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-order-to-payment
spec:
  podSelector:
    matchLabels:
      app: payment-service     # 目标：payment-service 的 Pod
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: order-service   # 来源：order-service 的 Pod
      ports:
        - protocol: TCP
          port: 8443

NetworkPolicy 的三个关键限制：

1. 只能控制 L3/L4：可以控制”谁”在”哪个端口”上通信，不能控制 HTTP 方法、路径或 gRPC 服务名。
2. 依赖 CNI 插件实现：Kubernetes 本身只是 API 定义，实际的执行取决于 CNI（Calico、Cilium、Weave 等）。不兼容的 CNI 静默忽略 NetworkPolicy。
3. 没有审计模式：NetworkPolicy 一旦创建就直接生效——如果规则有误，合法流量被直接丢弃，没有”先记录后拒绝”的过渡期。

1.4 Cilium: 基于身份的 eBPF 执行

Cilium 的微分段模型与前三层有本质区别——它的安全原语不是 IP 地址，而是数字身份（Numeric Identity）。

Cilium 为每个 Pod 分配一个全局唯一的 16 位数字 Identity。eBPF 程序在网络数据通路中根据 Identity 查找策略 map，做出 allow/deny 决策——整个过程在内核中完成，不涉及 iptables。

请求到达 Cilium datapath:
  1. eBPF 程序从包中提取源 Pod 的 Identity（从包标记/标签）
  2. 查询策略 map: 源 Identity → 目标 Identity + 端口 → allow/deny
  3. 决策在内核中执行（无用户态切换）

CiliumNetworkPolicy（CRD）扩展了标准 NetworkPolicy，增加了 L7 能力和 DNS/FQDN 策略：

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "payment-l7-policy"
spec:
  endpointSelector:
    matchLabels:
      app: payment-service
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: order-service
      toPorts:
        - ports:
            - port: "8443"
              protocol: TCP
          rules:
            http:
              - method: "POST"
                path: "/charge"
              - method: "POST"
                path: "/refund"
    - fromEndpoints:
        - matchLabels:
            app: admin-service
      toPorts:
        - ports:
            - port: "8443"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/health"

Cilium 的 L7 策略需要对 HTTP 流量做协议解析——这需要把包从内核态送入用户态的 Envoy sidecar 做深度包检测（DPI），然后再回到内核态进行转发。这会引入性能开销——这也是 Cilium 不使用 L7 策略时能保持极高吞吐量的原因。

1.5 Istio AuthorizationPolicy

Istio 的微分段在服务网格层面实现——Envoy sidecar 在每个 Pod 旁边执行 L7 策略：

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: payment-service-policy
spec:
  selector:
    matchLabels:
      app: payment-service
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - "cluster.local/ns/production/sa/order-service"
      to:
        - operation:
            methods: ["POST"]
            paths: ["/charge", "/refund"]
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: default-deny
spec: {}
# 空的 AuthorizationPolicy = 默认拒绝所有请求

Istio 的 AuthorizationPolicy 可以基于 mTLS 身份（principals）进行判断——不依赖网络层的任何信息（IP、端口、label），只依赖 X.509 证书中的 SPIFFE ID。这与零信任”基于身份而非网络位置做决策”的原则完全一致。

二、微分段实施的四阶段策略

从”全通”到”全白名单”不能一步到位。实施过程分四个阶段：

Phase 1: 可观测性

在不阻断任何流量的前提下，部署流量监控工具（Cilium Hubble、Istio Kiali、Calico 流量日志），绘制完整的服务间调用关系图：

# Cilium Hubble: 观察流量但不阻断
cilium hubble observe --from-namespace production

这一阶段的产物是一张服务间通信矩阵——哪个服务正在向哪个服务发送请求。所有在矩阵之外的通信都应该被质疑：“为什么 frontend 在直接访问数据库？”

Phase 2: 粗粒度分段

按命名空间或业务域划分安全区域。这些规则的变化频率低、影响范围大、且不容易出错：

# 禁止 dev 命名空间访问 production 命名空间
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-dev-to-prod
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              environment: production    # 只允许来自 production 命名空间的流量

Phase 3: 细粒度服务级策略

在每个安全区域内部，按服务级别制定白名单策略。这一阶段工作量最大——为每个服务梳理其合法的上下游依赖：

payment-service 的入站依赖:
  - order-service → POST /charge (创建支付)
  - order-service → POST /refund (退款)
  - admin-service → GET /health (健康检查)
  - admin-service → GET /transactions/* (交易查询)
  
payment-service 的出站依赖:
  - payment-db → TCP 5432
  - notification-service → POST /send

每一对依赖都需要一条策略。200 个微服务 = 可能 500+ 条入站/出站策略。策略数量是 O(n) 的服务间连接边数。

Phase 4: L7 精确策略

在服务网格中配置 L7 级别的策略，控制到 HTTP 方法和路径。这一阶段最精细但运维成本也最高——每次 API 变更（新增端点、废弃端点）都需要同步更新策略。

每个阶段都应在审计模式（Audit Mode / Shadow Mode）下运行足够长的时间，确认不会误杀合法流量后再切换到强制模式。Istio 支持通过 action: AUDIT 而非 action: ALLOW 先在 shadow mode 运行：

# Istio 的 shadow mode: 仅在日志中记录策略匹配，不实际拒绝
spec:
  action: AUDIT

三、工程坑点

3.1 策略管理成本的爆炸

微分段的核心张力不是技术问题——策略越精确，管理成本越高。一个团队需要在以下之间找到平衡：

• 过宽的策略：允许整个命名空间访问 → 安全收益低
• 过窄的策略：精确到每个 HTTP 方法 + 路径 → 运维成本极高

200 个微服务的 L7 白名单策略总量可能在 500-2000 条之间。每次新增一个服务端点都需要更新 1-10 条策略。如果策略更新需要 2 天（PR 审核 + CI 测试 + Shadow mode），新增端点的上线速度从”合并即上线”变成”两天后上线”。

3.2 东西向流量的规模

微服务架构中的东西向流量（服务间调用）通常远大于南北向流量（客户端到服务端）。一个用户请求可能触发 20 个服务间调用——如果为这 20 个调用做每次请求的 L7 策略评估，延迟会累积。

Cilium 在 eBPF 层面做 L3/L4 的 Identity-based 微分段（内核态，极低开销），但 L7 策略需要将包送给 Envoy sidecar（用户态）解析 HTTP 协议——这个用户态往返的开销在 0.1-0.5ms 之间。对于 20 跳的调用链，累积的延迟在 2-10ms——在单跳延迟本来只有 1-2ms 的内部网络中，这是翻倍的开销。

3.3 多集群微分段

跨 K8s 集群的微分段比单集群复杂得多：

• Cilium ClusterMesh：将多个集群的 Identity 空间合并，允许跨集群的策略引用
• Istio Multi-Cluster：将不同集群的服务注册到同一个服务网格

但两者都有根本性的限制——跨集群的微分段策略不能依赖集群本地的 label selector，因为 label 在不同集群之间不共享。跨集群策略通常只能使用更粗粒度的选择器（SPIFFE ID、命名空间名称）。

四、总结

微分段的四层技术栈不是”更高就是更好”——每一层在安全收益和运维成本之间有自己的平衡点。选择的原则：

• VLAN/ACL：适合非容器化的传统环境
• Kubernetes NetworkPolicy：适合中小 K8s 集群，安全要求中等
• Cilium Identity-based：适合大规模 K8s 集群，需要高性能 eBPF 数据面
• Istio AuthorizationPolicy：适合需要 L7 精度且可接受 sidecar 开销的场景

大多数组织的微分段不会只选择一层——而是在核心服务间使用 L7 Istio 策略，在普通服务间使用 Cilium L3/L4 Identity 策略，在命名空间边界使用 NetworkPolicy。

下一篇：mTLS 大规模部署的工程现实。

参考资料

1. Cilium. Documentation: Network Policy. https://docs.cilium.io/en/stable/security/policy/
2. Istio. Authorization Policy. https://istio.io/latest/docs/reference/config/security/authorization-policy/
3. Kubernetes. Network Policies. https://kubernetes.io/docs/concepts/services-networking/network-policies/
4. Cilium. Cluster Mesh. https://docs.cilium.io/en/stable/network/clustermesh/