4、微隔离技术实战：基于网络功能（NF）的微分段、使用Service Mesh（如Istio）实现东西向流量隔离、在Kubernetes上部署微隔离策略

4.1 为什么微隔离是核心网零信任的“最后一公里”

说实话，我在做核心网云化项目之前，对微隔离的理解还停留在“防火墙策略细化”这个层面。直到有一次，我们在现网测试5G核心网的UPF和SMF之间的东西向流量，发现一旦某个Pod被攻破，攻击者可以横向移动到相邻的NF实例——那一刻我才真正意识到，南北向防火墙根本挡不住东西向的威胁。

微隔离，说白了就是在数据中心内部，把网络切成极细的“格子”。每个格子里的服务只能访问它该访问的东西。你想想看，5G核心网里AMF、SMF、UPF、PCF这些NF之间，通信关系是固定的、可预期的。这就给了我们做微分段的绝佳条件。

核心观点：微隔离不是“加防火墙”，而是“重新定义网络边界”。在Kubernetes环境下，边界不再是IP和端口，而是服务身份和标签。

4.2 基于网络功能（NF）的微分段设计

我习惯把微分段分成三个层次：

  • 第一层：NF级别的隔离——比如AMF和SMF属于不同的安全域，它们之间默认不通。
  • 第二层：NF实例级别的隔离——同一个NF的不同实例（比如两个AMF实例），只允许通过服务网格通信。
  • 第三层：工作负载级别的隔离——Pod级别的细粒度策略，精确到每个容器的进出流量。

举个例子。我在一个项目中，需要让SMF只能被AMF和PCF访问，而UPF只能被SMF访问。传统做法是配一堆ACL，但维护起来简直是噩梦。用微隔离的话，我们只需要定义几条策略：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: smf-authz
  namespace: 5g-core
spec:
  selector:
    matchLabels:
      app: smf
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/5g-core/sa/amf-sa"]
    - source:
        principals: ["cluster.local/ns/5g-core/sa/pcf-sa"]
    to:
    - operation:
        ports: ["80", "443"]

嗯，这里要注意：NF的标签设计一定要规范。我见过不少团队，标签随便起，结果策略写出来自己都看不懂。我的建议是：统一用 nf-type、nf-instance、security-zone 三个标签，分别表示NF类型、实例编号和安全域。

4.3 使用Service Mesh（Istio）实现东西向流量隔离

为什么选Istio？因为它在Kubernetes上做东西向流量隔离，简直是天生一对。Istio的Sidecar代理会拦截所有进出Pod的流量，然后根据你定义的策略做授权和加密。

我记得有一次，客户问：“你们怎么保证SMF和UPF之间的流量不被篡改？”我直接给他们看了Istio的mTLS配置：

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: 5g-core
spec:
  mtls:
    mode: STRICT
  portLevelMtls:
    8080:
      mode: DISABLE  # 某些监控端口可以不用mTLS

说白了，STRICT模式意味着所有东西向流量都必须经过TLS加密。你想想看，就算攻击者进了Pod，没有合法的证书，他也发不出任何请求。

但这里有个坑——性能开销。我曾经在一个高吞吐的UPF场景下测试，开了mTLS后CPU开销增加了15%左右。所以我的建议是：核心网的控制面NF（AMF、SMF、PCF）可以全量开启mTLS，但用户面NF（UPF）要按需开启，或者只在关键信令链路上启用。

实战技巧：在Istio中，可以用 AuthorizationPolicy 结合 PeerAuthentication 实现“先认证、后授权”的两层防护。先确保对方身份可信，再判断它有没有权限访问。

4.4 在Kubernetes上部署微隔离策略

部署微隔离策略，我建议分三步走：

  1. 第一步：梳理通信矩阵——画出所有NF之间的通信关系图。哪个NF需要访问哪个NF的哪个端口？协议是什么？
  2. 第二步：定义安全域——把NF分成几个安全域，比如“信令域”、“用户面域”、“管理域”。域内默认允许，域间默认拒绝。
  3. 第三步：逐步下发策略——先以“审计模式”运行，只记录不拦截。确认无误后再切换到“强制模式”。

我画了一张图，帮你理解这个流程：

微隔离策略部署流程 第一步 梳理通信矩阵 第二步 定义安全域 第三步 逐步下发策略 NF类型、端口、协议 谁访问谁？用什么协议？ 信令域 / 用户面域 / 管理域 域内允许，域间拒绝 审计模式 → 强制模式 先记录，再拦截 关键原则：最小权限 + 默认拒绝 + 持续监控 图：微隔离策略部署三阶段

部署的时候，我强烈建议用GitOps的方式管理策略。把所有的AuthorizationPolicy、PeerAuthentication都写成YAML文件，放到Git仓库里。这样每次变更都有记录，回滚也方便。

避坑指南：我曾经在现网直接下发了一条“拒绝所有”的策略，结果把监控系统也拦了，导致告警全断。所以记住：先加白名单，再加黑名单。而且一定要保留一个“管理通道”的例外策略，确保运维人员能随时登录。

4.5 实战案例：5G核心网SMF的微隔离配置

最后，我分享一个完整的配置示例。假设我们要保护SMF，只允许AMF和PCF访问它：

# 1. 启用mTLS
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: smf-mtls
  namespace: 5g-core
spec:
  selector:
    matchLabels:
      app: smf
  mtls:
    mode: STRICT
---
# 2. 定义授权策略
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: smf-access
  namespace: 5g-core
spec:
  selector:
    matchLabels:
      app: smf
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/5g-core/sa/amf-sa"]
    - source:
        principals: ["cluster.local/ns/5g-core/sa/pcf-sa"]
    to:
    - operation:
        methods: ["GET", "POST"]
        ports: ["8080"]
  - from:
    - source:
        namespaces: ["istio-system"]
    to:
    - operation:
        ports: ["15020"]  # 允许Istio健康检查
---
# 3. 默认拒绝所有其他流量
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: smf-deny-all
  namespace: 5g-core
spec:
  selector:
    matchLabels:
      app: smf
  action: DENY
  rules:
  - from:
    - source:
        notPrincipals: ["*"]

嗯，这里有个细节：DENY策略的优先级高于ALLOW。所以上面的配置逻辑是：先允许AMF和PCF访问，再拒绝其他所有。如果你反过来写，那AMF和PCF也会被拒绝。

说实话，微隔离这东西，策略本身不难写，难的是梳理清楚通信关系。我建议你从最简单的场景开始，比如先保护一个NF，跑通了再扩展到整个核心网。别想着一步到位，那只会让你陷入策略冲突的泥潭。

我的个人习惯：每写一条策略，都在旁边注释上“为什么允许这个访问”。三个月后回头看，你会感谢自己的这个习惯。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →