📚 课程目录第4章微分段与微服务

4. 微分段与微服务：微服务架构下的安全挑战

微服务火了这么多年，大家享受了它的弹性、独立部署、技术异构。但说实话，安全这块一直是「补丁式」推进的。我见过不少团队，微服务拆了上百个，安全策略还停留在「所有 Pod 互相信任」的阶段。这不出事才怪。

4.1 微服务架构下的安全挑战

传统单体应用，安全边界就是防火墙。东西流量很少，南北流量管住就行。微服务一拆，情况变了——服务之间要频繁通信，东西流量暴涨。你想想看，原来一个请求只在进程内调用，现在变成跨网络调用。攻击面一下就大了。

我总结了几类常见的安全挑战：

东西流量不可控：服务 A 可以随意访问服务 B 的数据库端口，没人管。
身份与信任扩散：一旦某个 Pod 被攻破，攻击者可以在集群内横向移动。
加密与认证碎片化：有的服务用 mTLS，有的用 JWT，有的干脆裸奔。
策略管理混乱：iptables、网络策略、应用层白名单混在一起，改一次策略要改好几个地方。

核心矛盾：微服务要求「零信任」，但传统网络模型默认「内部可信」。微分段就是来解决这个矛盾的。

4.2 微分段在 Kubernetes 中的应用

Kubernetes 原生提供了 NetworkPolicy，这算是微分段在容器领域最基础的落地形式。但说实话，光靠 NetworkPolicy 远远不够。为什么？

NetworkPolicy 只能管 L3/L4 层，也就是 IP 和端口。应用层的东西它管不了。而且策略粒度只能到 Pod 级别，没法做到进程级别或 API 级别。我在项目中遇到过一个问题：两个服务用了同一个 Namespace，NetworkPolicy 允许它们通信，结果其中一个服务被注入了恶意代码，直接通过 HTTP 请求把另一个服务的数据库拖走了。NetworkPolicy 完全没拦住，因为端口是合法的。

所以，Kubernetes 下的微分段，需要分层来做：

层次	技术手段	粒度	典型工具
L3/L4 网络层	NetworkPolicy	Pod / Namespace	Calico, Cilium
L7 应用层	服务网格 / API 网关	HTTP 方法 / 路径 / 头	Istio, Linkerd, Envoy
身份与认证	mTLS / SPIFFE	工作负载身份	Istio, SPIRE

我个人习惯的做法是：先用 NetworkPolicy 做粗粒度隔离，把不同敏感等级的服务隔开。然后再用服务网格做细粒度控制。两层配合，才能做到真正的微分段。

避坑指南：我曾经见过一个团队，NetworkPolicy 写得太细，每个 Pod 之间都要显式放行，结果上线时漏了一条策略，服务间调用全断了。建议先以 Namespace 为单位做隔离，再逐步细化到 Pod 级别。

4.3 服务网格与微分段

服务网格的出现，让微分段从「网络层隔离」进化到了「应用层安全」。说白了，服务网格把安全逻辑从业务代码里抽了出来，放到了 Sidecar 里。这样业务团队不用改代码，就能获得 mTLS、细粒度访问控制、可观测性。

Istio 是我用得最多的服务网格。它的 AuthorizationPolicy 可以做到非常细的微分段控制。举个例子：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payment-service-policy
  namespace: default
spec:
  selector:
    matchLabels:
      app: payment
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/order-service"]
    to:
    - operation:
        methods: ["POST"]
        paths: ["/api/v1/charge"]

这段策略的意思是：只有 order-service 的 ServiceAccount 才能调用 payment 服务的 /api/v1/charge 接口，而且只能用 POST 方法。其他任何来源、任何方法，都会被拒绝。

你想想看，这种粒度，NetworkPolicy 根本做不到。而且 Istio 的 mTLS 是自动开启的，服务之间的流量默认加密。攻击者就算拿到了 Pod 的 Shell，也没法直接嗅探流量。

不过，服务网格也不是银弹。它引入了额外的延迟和资源开销。每个请求都要经过 Sidecar 处理，CPU 和内存消耗是实打实的。我建议在关键业务路径上启用 mTLS 和细粒度策略，非关键路径可以放宽一些。

注意：服务网格的微分段策略是「有状态」的。如果你改了策略，需要等 Sidecar 重新加载配置。这个过程中可能会有短暂的策略不一致。建议在变更窗口期操作，或者先做灰度验证。

下面这张图展示了服务网格如何实现微分段：

从图上可以看到，服务 A 和 B 之间的流量不再直连，而是通过各自的 Sidecar 代理。控制面负责下发策略，Sidecar 负责执行。这样，安全逻辑完全从业务代码中剥离了。

嗯，这里要注意一点：服务网格的微分段策略是「声明式」的。你只需要告诉控制面「谁可以访问谁」，剩下的 Sidecar 会自动处理。但这也意味着，策略的变更需要经过控制面下发，有一定的延迟。我建议在测试环境先验证策略效果，再推到生产。

最后说一句，微分段不是一蹴而就的。从 NetworkPolicy 到服务网格，每一步都有代价。但如果你问我，微服务架构下安全最值得投入的方向是什么？我会毫不犹豫地说：微分段。因为它解决的是最根本的问题——信任边界。