第一部分：开篇明义 —— 定义、价值与目标

定位与价值

在云原生架构中，容器网络是承载所有微服务通信的血脉。其安全性直接决定了应用集群的“免疫系统”强度。传统的边界防火墙在动态、弹性的容器环境中力不从心，安全能力必须下沉到集群内部，与网络基础设施深度融合。本文探讨的容器网络接口（CNI）、网络策略（NetworkPolicy） 与服务网格（Service Mesh） 的集成，正是构建下一代“零信任”容器网络安全的三大支柱。理解它们的协同工作机制，是设计、攻防和运维现代化云原生平台的核心能力。

学习目标

读完本文，你将能够：

1. 阐述 CNI、Kubernetes 网络策略及服务网格在安全层面各自的核心职责与根本局限性。
2. 操作 在真实 Kubernetes 环境中，配置并验证网络策略对 Pod 流量的隔离效果。
3. 分析 服务网格（以 Istio 为例）如何增强并超越传统网络策略，提供应用层（L7）的零信任安全能力。
4. 构建 一个结合网络策略（L3/L4）与服务网格策略（L7）的分层纵深防御体系，并能制定相应的检测与响应线索。
5. 评估 在具体业务场景下，如何选择与集成这些技术以达成最优的安全与可观测性平衡。

前置知识

· Kubernetes 核心概念：了解 Pod、Service、Namespace、Label 和 Selector 的基本概念（参见大纲文章 K8S-FND-001）。
· 基础网络知识：熟悉 OSI 七层模型，特别是 L3（网络层/IP）、L4（传输层/TCP/UDP）和 L7（应用层/HTTP/gRPC）的区别。
· Linux 网络命名空间：理解容器网络隔离的基本原理。

---

第二部分：原理深掘 —— 从“是什么”到“为什么”

核心定义与类比

1. CNI：网络的“基础设施层”
   · 定义：CNI 是一个标准规范与插件生态系统，负责在容器（Pod）创建时为其分配网络资源（如IP地址），并将其连接到集群网络中。它决定了连通性，是所有通信的物理与链路基础。
   · 类比：如同一个超级集装箱码头的“桥吊和路网系统”。CNI 插件（如 Calico, Flannel, Cilium）负责将每个集装箱（Pod）从船上卸下，分配一个唯一的门牌号（IP），并修建通往码头内所有其他区域的道路（Overlay/Underlay 网络）。它确保货物（数据包）能从 A 点物理上到达 B 点。
2. Kubernetes 网络策略：网络的“基础防火墙”
   · 定义：NetworkPolicy 是 Kubernetes 内置的一种资源，用于控制 Pod 组之间以及 Pod 与外部世界之间的网络流量。它基于标签选择器定义允许（Allow） 的入口（Ingress）和出口（Egress）规则。它默认遵循“默认拒绝”（默认允许一切）。
   · 类比：如同码头内部各个仓库区域间的“关卡和通行证检查”。它不负责修路，而是在已有的道路上设置检查点。规则可能是“只有贴有‘生鲜部’标签的卡车才能进入冷库区”，检查维度是车牌号（IP/端口）和货物类型（TCP/UDP）。它工作在 L3/L4 层。
3. 服务网格：网络的“智能应用层代理”
   · 定义：Service Mesh 是一个专用的基础设施层，用于处理服务间通信。它通过将网络功能（如负载均衡、熔断、认证）以边车代理的形式注入到每个应用 Pod 中来实现。它提供应用层的可观测性、流量控制和安全。
   · 安全类比：如同为每个集装箱配备一个“智能护航员和海关官员”。这个官员不仅检查卡车来自哪个仓库（L3/L4），还能打开集装箱，检查里面的货物清单（HTTP 头部、gRPC 方法）、验证送货员的身份证件（mTLS 证书）、甚至对货物进行 X 光扫描（请求体检查）。它工作在 L7 层。

根本原因分析：为何需要三层协同？

· CNI 的安全局限性：CNI 提供了连接，但缺乏访问控制。在默认安装的 Kubernetes 集群中，所有 Pod 可以相互通信，这为攻击者横向移动提供了广阔空间。
· 网络策略的局限性：

1. 粒度粗：只能控制到 IP 和端口，无法区分同一个端口上的不同 HTTP 路径或 gRPC 服务。
2. 协议盲：无法理解应用层协议，无法基于 HTTP 方法、Header、JWT 声明等实施策略。
3. TLS 盲：面对加密流量（如 HTTPS），网络策略无法进行内容检查，只能“全放行”或“全拒绝”。
4. 实现依赖：需要底层 CNI 插件支持（不是所有插件都完整支持 NetworkPolicy）。
   · 服务网格的引入：正是为了弥补网络策略在应用层（L7） 和身份驱动安全方面的不足。它引入了基于强身份（通过自动 mTLS）的零信任网络，并能实施极其精细的策略。

可视化核心机制：三层安全架构演进

下图展示了从基础的 CNI 网络，到引入网络策略，再到与服务网格集成的安全能力演进路径。

图表说明：

阶段一：基础连通（仅CNI）

· 特点：默认Allow All，所有Pod间任意流量可达
· 风险：攻击面最大，横向移动无限制
· 图示：Pod A ↔ Pod B ↔ Pod C（双向互通）

阶段二：网络隔离（CNI + NetworkPolicy）

· 特点：基于标签的L3/L4层访问控制
· 实现：
· frontend Pod只能访问api Pod的80端口
· api Pod只能访问database Pod的3306端口
· database Pod到api Pod的访问被拒绝
· 优势：实现基本网络分段，减少攻击面

阶段三：零信任网络（集成Service Mesh）

· 特点：基于身份的应用层安全控制
· 实现：

1. 自动mTLS：Pod间通信自动加密，基于强身份认证
2. L7策略检查：支持HTTP方法、路径、Header等精细控制
3. 精细控制：可实施SQL语句级别的访问控制
4. 外部防御：拒绝非mTLS连接和未知身份访问
   · 优势：真正的零信任网络，深度防御

技术要点：

1. 兼容性：此图表使用标准Mermaid语法，确保最大兼容性
2. 可读性：使用颜色区分三个阶段，清晰展示演进路径
3. 信息密度：平衡了信息量和视觉清晰度

---

第三部分：实战演练 —— 从“为什么”到“怎么做”

环境与工具准备

· 演示环境：一个包含至少两个 Worker 节点的 Kubernetes 集群（可使用 KinD, k3s, 或任何公有云 K8s 服务）。
· 核心工具：
· kubectl (v1.24+)
· helm (v3.0+)
· curl / netshoot 容器（用于网络测试）
· CNI 插件：我们选择 Calico，因为它对网络策略有成熟且高性能的实现，同时其较新版本（Cilium 也是）本身也具备了部分服务网格的能力，但本文仍以经典的边车模式为例。
· Service Mesh：我们选择 Istio，作为业界最主流的服务网格实现。
· 实验环境搭建（使用 KinD）：

# kind-cluster-with-calico.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
networking:
  disableDefaultCNI: true # 禁用 KinD 自带的 CNI
  podSubnet: "192.168.0.0/16"
nodes:
  - role: control-plane
  - role: worker
  - role: worker

# 1. 创建集群
kind create cluster --name=net-sec-demo --config=kind-cluster-with-calico.yaml

# 2. 安装 Calico CNI (包括网络策略支持)
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/tigera-operator.yaml
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/custom-resources.yaml
# 等待所有 `calico-*` pod 变为 Running 状态
kubectl wait --for=condition=ready pod -l k8s-app=calico-node -n calico-system --timeout=300s

# 3. 验证 CNI 与基础网络
kubectl run test-nginx --image=nginx:alpine
kubectl run test-client --image=nicolaka/netshoot --command -- sleep 3600
# 在 test-client pod 内执行 `curl <test-nginx_pod_ip>`，应能访问到 nginx 欢迎页。

标准操作流程

步骤1：构建微服务应用与默认无策略状态

# 创建示例命名空间
kubectl create ns demo-app

# 部署一个简单的“前端-后端”应用
cat <<EOF | kubectl apply -n demo-app -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 2
  selector:
    matchLabels:
      app: frontend
      tier: web
  template:
    metadata:
      labels:
        app: frontend
        tier: web
    spec:
      containers:
      - name: app
        image: gcr.io/google-samples/hello-app:2.0
        env:
        - name: "PORT"
          value: "8080"
---
apiVersion: v1
kind: Service
metadata:
  name: frontend-service
spec:
  selector:
    app: frontend
    tier: web
  ports:
  - port: 80
    targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
spec:
  replicas: 2
  selector:
    matchLabels:
      app: backend
      tier: api
  template:
    metadata:
      labels:
        app: backend
        tier: api
    spec:
      containers:
      - name: app
        image: gcr.io/google-samples/hello-app:2.0
        env:
        - name: "PORT"
          value: "8080"
        - name: "MESSAGE"
          value: "Backend Service"
---
apiVersion: v1
kind: Service
metadata:
  name: backend-service
spec:
  selector:
    app: backend
    tier: api
  ports:
  - port: 80
    targetPort: 8080
EOF

# 部署一个“数据库” Pod（模拟敏感服务）
kubectl run database --image=redis:alpine -n demo-app --labels="app=database,tier=data"

# 验证默认连通性（一切皆可通）
kubectl run attacker --image=nicolaka/netshoot -n demo-app --rm -it --command -- curl -s http://backend-service.demo-app.svc.cluster.local
# 应返回 “Backend Service”
kubectl exec -n demo-app -it attacker -- curl -s http://database.demo-app:6379
# 虽然返回的不是有效Redis响应，但TCP连接是成功的，证明可以访问。

步骤2：利用网络策略实施L3/L4层隔离

现在，我们希望实现：

1. frontend Pod 可以访问 backend Service 的 80 端口。
2. backend Pod 可以访问 database Pod 的 6379 端口。
3. 其他所有流量（包括从 frontend 直接到 database，或从外部到 backend）都被拒绝。

# network-policy-demo.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: demo-app
spec:
  podSelector:
    matchLabels:
      app: backend
      tier: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
          tier: web
    ports:
    - protocol: TCP
      port: 80
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-database
  namespace: demo-app
spec:
  podSelector:
    matchLabels:
      app: database
      tier: data
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend
          tier: api
    ports:
    - protocol: TCP
      port: 6379
---
# 一个“默认拒绝所有入站”的策略，作为安全基线。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: demo-app
spec:
  podSelector: {} # 选择所有 Pod
  policyTypes:
  - Ingress
  ingress: [] # 空规则列表 => 拒绝所有入站

kubectl apply -f network-policy-demo.yaml

# 验证策略生效
# 1. Frontend -> Backend 应成功
kubectl exec -n demo-app deployment/frontend -- curl -s --connect-timeout 5 http://backend-service.demo-app.svc.cluster.local
# 2. Attacker (无 frontend 标签) -> Backend 应失败
kubectl run attacker2 --image=nicolaka/netshoot -n demo-app --rm -it --command -- curl -s --connect-timeout 5 http://backend-service.demo-app.svc.cluster.local
# 3. Frontend -> Database (6379) 应失败
kubectl exec -n demo-app deployment/frontend -- curl -s --connect-timeout 5 telnet://database.demo-app:6379
# 4. Backend -> Database (6379) 应成功（需进入backend pod测试）
kubectl exec -n demo-app deployment/backend -- sh -c 'timeout 5 redis-cli -h database.demo-app -p 6379 PING'
# 应返回 “PONG” 或类似响应。

步骤3：集成服务网格，引入L7层安全与mTLS

现在我们在已有网络策略的基础上，引入 Istio 来提供 L7 安全和可观测性。

# 1. 安装 Istio (使用 demo 配置 profile，包含 ingress gateway 等)
curl -L https://istio.io/downloadIstio | sh -
cd istio-*
export PATH=$PWD/bin:$PATH
istioctl install --set profile=demo -y

# 2. 给 demo-app 命名空间打上标签，启用 Istio Sidecar 自动注入
kubectl label namespace demo-app istio-injection=enabled
# 重启应用 Deployment 以注入 Sidecar
kubectl rollout restart deployment -n demo-app

# 3. 验证 Sidecar 注入
kubectl get pods -n demo-app
# 每个 Pod 的 READY 列应为 2/2（应用容器 + istio-proxy 容器）

# 4. 此时，Pod 间的通信已自动升级为 mTLS。
# 我们可以创建一个 PeerAuthentication 策略来强制命名空间内全局 mTLS。
cat <<EOF | kubectl apply -n demo-app -f -
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
spec:
  mtls:
    mode: STRICT
EOF

步骤4：实施应用层（L7）授权策略

假设我们想实现比网络策略更细的规则：frontend 只能对 backend 发起 GET 请求，不能发起 POST 请求。

网络策略无法做到这一点，但 Istio 的 AuthorizationPolicy 可以。

# istio-l7-policy.yaml
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-get-to-backend
  namespace: demo-app
spec:
  selector:
    matchLabels:
      app: backend
      tier: api
  action: ALLOW # 默认是 ALLOW，但配合规则使用
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/demo-app/sa/default"] # 来源身份（前端Pod使用的Service Account）
    to:
    - operation:
        methods: ["GET"]
        paths: ["/*"] # 允许所有路径的 GET 请求
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all-to-backend
  namespace: demo-app
spec:
  selector:
    matchLabels:
      app: backend
      tier: api
  action: DENY # 显式拒绝所有不匹配上面 ALLOW 规则的请求
EOF

kubectl apply -f istio-l7-policy.yaml

# 验证 L7 策略生效
# 1. Frontend 发起 GET 请求，应成功
kubectl exec -n demo-app deployment/frontend -- curl -s -X GET http://backend-service.demo-app.svc.cluster.local
# 2. Frontend 发起 POST 请求，应被拒绝 (RBAC: access denied)
kubectl exec -n demo-app deployment/frontend -- curl -s -X POST http://backend-service.demo-app.svc.cluster.local -d "test"
# 3. 查看 Envoy 代理的日志，可以看到详细的访问控制和拒绝信息
kubectl logs -n demo-app deployment/frontend -c istio-proxy --tail=5

自动化与脚本：策略审计与验证工具

以下 Python 脚本片段可用于快速审计一个命名空间内哪些 Pod 受到网络策略保护，以及策略规则概况。

#!/usr/bin/env python3
"""
K8s 网络策略简易审计脚本
# 警告：此脚本仅用于授权测试环境的资产清点和安全审计。
"""

import subprocess
import json
import sys
from typing import List, Dict

def get_namespace_policies(namespace: str) -> List[Dict]:
    """获取指定命名空间的所有 NetworkPolicy 资源。"""
    cmd = ["kubectl", "get", "networkpolicy", "-n", namespace, "-o", "json"]
    try:
        result = subprocess.run(cmd, capture_output=True, text=True, check=True)
        data = json.loads(result.stdout)
        return data.get("items", [])
    except subprocess.CalledProcessError as e:
        print(f"错误：无法获取 {namespace} 的网络策略。", file=sys.stderr)
        print(e.stderr, file=sys.stderr)
        return []
    except json.JSONDecodeError as e:
        print(f"错误：解析 JSON 失败。", file=sys.stderr)
        return []

def analyze_policy(policy: Dict) -> None:
    """分析并打印单个策略的关键信息。"""
    metadata = policy.get("metadata", {})
    spec = policy.get("spec", {})
    
    name = metadata.get("name", "N/A")
    pod_selector = spec.get("podSelector", {})
    
    print(f"\n策略名称: {name}")
    print(f"  目标 Pod 选择器: {pod_selector}")
    
    # 分析入站规则
    ingress_rules = spec.get("ingress", [])
    if ingress_rules:
        print(f"  入站规则 ({len(ingress_rules)} 条):")
        for i, rule in enumerate(ingress_rules, 1):
            from_sources = rule.get("from", [])
            ports = rule.get("ports", [])
            print(f"    规则 {i}:")
            for src in from_sources:
                if "podSelector" in src:
                    print(f"      允许来自 Pod: {src['podSelector']}")
                if "namespaceSelector" in src:
                    print(f"      允许来自命名空间: {src['namespaceSelector']}")
                if "ipBlock" in src:
                    print(f"      允许来自 IP 段: {src['ipBlock']}")
            for port in ports:
                print(f"      端口/协议: {port.get('port')}/{port.get('protocol', 'TCP')}")
    else:
        print(f"  入站规则: 无 (拒绝所有入站)")
    
    # 分析出站规则
    egress_rules = spec.get("egress", [])
    # ... (类似逻辑，此处省略)

def main():
    if len(sys.argv) != 2:
        print(f"用法: {sys.argv[0]} <namespace>")
        sys.exit(1)
    
    namespace = sys.argv[1]
    print(f"正在审计命名空间: {namespace}")
    
    policies = get_namespace_policies(namespace)
    
    if not policies:
        print("未发现任何 NetworkPolicy。默认允许所有 Pod 间通信，存在安全风险！")
        return
    
    print(f"共发现 {len(policies)} 条 NetworkPolicy。")
    for policy in policies:
        analyze_policy(policy)

if __name__ == "__main__":
    main()

对抗性思考：绕过与进化

在集成了服务网格的现代集群中，攻击者的路径变得更加困难，但并非不可能。

1. 绕过网络策略：如果网络策略配置错误（如选择器过宽），攻击者可能通过控制一个有特权的 Pod 进行横向移动。防御：确保策略遵循最小权限原则，并使用 kubectl network-policy 等工具进行模拟测试。
2. 针对 Sidecar 的攻击：边车代理本身是一个攻击面。历史上有 CVE 影响 Envoy。攻击者可能尝试利用代理漏洞进行权限提升或流量劫持。防御：及时更新服务网格控制面和数据面版本，限制边车容器的权限（如不使用 privileged: true）。
3. 滥用合法凭证：服务网格的 mTLS 和 L7 策略基于身份。如果攻击者窃取了某个 Service Account 的令牌，或者应用本身被入侵（如前端服务器被上传 Webshell），它就能以合法身份进行通信。防御：实施细粒度的授权策略，结合请求认证（如 JWT 验证），并定期轮换服务账户令牌。
4. 直接宿主机网络：Pod 如果以 hostNetwork: true 运行，则可能绕过 CNI 管理的网络。防御：使用 Pod 安全标准（Pod Security Standards）或准入控制器（如 OPA Gatekeeper, Kyverno）禁止或严格审计使用主机网络的 Pod。

---

第四部分：防御建设 —— 从“怎么做”到“怎么防”

开发侧修复：安全微服务设计与通信规范

开发者在设计微服务时，就应为安全集成做好准备。

· 危险模式：服务间使用明文本地调用假设，无身份标识，随意暴露所有 API 端点。

# 服务部署清单（危险）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-service
spec:
  template:
    spec:
      containers:
      - name: app
        image: my-app:latest
        # 没有定义明确的端口协议，应用可能监听所有接口

· 安全模式：明确定义端口、协议和服务契约，使用标准服务发现，为集成服务网格做好准备。

# 服务部署清单（安全）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-secure-service
  labels:
    app: my-secure-service
    version: v1
spec:
  template:
    metadata:
      labels:
        app: my-secure-service
        version: v1
      annotations:
        # 为服务网格提供额外提示（如 Istio）
        sidecar.istio.io/inject: "true"
        traffic.sidecar.istio.io/includeInboundPorts: "8080"
    spec:
      serviceAccountName: my-service-account # 使用专用SA
      containers:
      - name: app
        image: my-app:secure
        ports:
        - containerPort: 8080
          name: http-api
          protocol: TCP
        env:
        - name: SERVICE_NAME
          value: "my-secure-service"
        - name: SERVICE_PORT
          value: "8080"
        # 应用内应能处理并传播追踪头（如 x-request-id）
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 30
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
            scheme: HTTP

# 对应的 Service 定义
apiVersion: v1
kind: Service
metadata:
  name: my-secure-service
spec:
  selector:
    app: my-secure-service
  ports:
  - port: 80
    targetPort: 8080
    name: http
  # 可选：创建对应的 Istio DestinationRule 用于定义负载均衡、TLS 设置等

运维侧加固：架构设计原则与配置清单

1. 分层防御架构：
   · L1（物理/云网络）：使用 VPC/子网隔离集群节点，配置安全组/防火墙限制非必要的节点间端口。
   · L2（CNI层）：选择支持网络策略且经过安全审计的 CNI 插件。考虑启用加密网络功能（如 WireGuard in Calico, IPSec in Cilium）以保护节点间流量。
   · L3（Kubernetes 网络策略层）：
   · 原则：默认拒绝所有入站/出站流量。
   · 清单：
   · 在每个命名空间应用一个 default-deny-all 策略。
   · 为每个微服务或应用层显式编写允许策略。
   · 策略的选择器要尽可能精确，避免使用空的 podSelector: {} 来允许流量。
   · 定期使用 kubectl describe networkpolicy 和审计工具审查策略。
   · L4（服务网格层）：
   · 原则：默认启用 mTLS，默认拒绝所有 L7 访问。
   · 清单：
   · 在网格内实施 STRICT mTLS 模式。
   · 为每个服务创建默认的 DENY all AuthorizationPolicy。
   · 基于服务身份（而非IP）和最小权限原则编写 L7 授权规则。
   · 启用详细的访问日志和指标，用于审计和异常检测。
2. 安全配置示例：

   # 1. 基线：拒绝所有入站 (Kubernetes NetworkPolicy)
   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: default-deny-ingress
     namespace: production
   spec:
     podSelector: {}
     policyTypes:
     - Ingress
   ---
   # 2. 基线：强制严格 mTLS (Istio PeerAuthentication)
   apiVersion: security.istio.io/v1beta1
   kind: PeerAuthentication
   metadata:
     name: default-strict-mtls
     namespace: production
   spec:
     mtls:
       mode: STRICT
   ---
   # 3. 基线：拒绝所有 L7 访问 (Istio AuthorizationPolicy)
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: default-deny-all
     namespace: production
   spec:
     selector: {} # 应用到命名空间内所有工作负载
     action: DENY
     rules: [] # 无规则，即拒绝所有请求
   # 注意：此后需要为每个服务显式添加 ALLOW 规则。
   

检测与响应线索

1. 网络策略违规检测：大多数 CNI 插件（如 Calico）会记录被丢弃的数据包。可在集群节点或集中式日志系统中监控 calico-fe 或 iptables 的 DROP 日志，寻找高频或异常的拒绝记录，这可能是扫描或配置错误。
2. 服务网格安全事件：
   · mTLS 失败：监控 Istio 代理指标 istio_requests_total{response_code=“401”} 或 istio_tcp_connections_closed_total 中的认证失败。
   · L7 策略拒绝：监控指标 istio_requests_total{response_code=“403”}。这是最主要的攻击行为指示器之一。
   · 异常流量模式：利用 Istio 的指标和分布式追踪，建立服务间通信的流量基线。检测异常的调用量、全新的调用关系或异常的延迟。
3. 威胁狩猎线索：如果发现一个 Pod 被入侵，立即：
   · 追溯：查看该 Pod 服务账户的所有授权策略，确定其理论访问范围。
   · 遏制：快速应用一个临时的、更严格的 NetworkPolicy 或 AuthorizationPolicy，隔离该 Pod。
   · 调查：通过服务网格访问日志，查询该 Pod（身份）在受影响时间窗口内发起的所有出站请求，寻找横向移动的证据。

---

第五部分：总结与脉络 —— 连接与展望

核心要点复盘

1. 分层协同是核心：CNI、网络策略和服务网格不是三选一，而是构成纵深防御的三层互补技术。CNI 管“连通”，网络策略管“L3/L4 访问”，服务网格管“L7 身份与内容”。
2. 零信任演进：从基于 IP 的粗放控制，演进到基于强身份（mTLS）和精细应用语义的零信任安全模型，是容器网络安全的必然趋势。
3. 安全左移与默认安全：应在设计部署之初就规划网络策略和服务网格的集成。采用“默认拒绝”原则，再根据需要逐个添加允许规则。
4. 可观测性是基石：没有强大的日志、指标和追踪能力，任何安全策略的效果都无法验证，入侵也无法检测。服务网格极大地增强了这方面的能力。

知识体系连接

· 前序基础：
· K8S-FND-001《Kubernetes 核心概念与架构安全》：本文中 Pod、Service、Namespace、Label 等概念的基础。
· CON-SEC-001《容器安全基础：镜像、运行时与供应链》：容器安全的前置知识，本文聚焦于运行时的网络层。
· 本文定位：K8S-SEC-002《容器网络安全：CNI、网络策略与服务网格集成》：作为 Kubernetes 运行时安全的网络核心篇章。
· 后继进阶：
· MESH-SEC-001《服务网格安全：Istio / Linkerd 深度攻防》：本文初步引入了服务网格的安全概念，该专题文章将深入剖析 mTLS 实现、授权策略漏洞、控制面安全及针对服务网格的渗透测试技巧。
· K8S-SEC-003《Kubernetes 高级威胁检测与威胁狩猎》：如何利用本文提到的日志和指标，构建主动的安全监控和事件响应体系。
· POL-SEC-001《云原生策略即代码：OPA/Gatekeeper 实战》：学习如何使用准入控制器强制执行本文提到的安全策略（如禁止 hostNetwork），实现策略的代码化管理。

进阶方向指引

1. eBPF 驱动的网络与安全：深入研究 Cilium 项目。它基于 eBPF 同时实现了高性能 CNI、超越 Kubernetes NetworkPolicy 能力的 CiliumNetworkPolicy（支持 DNS、FQDN 等）、以及服务网格数据面 Hubble。理解 eBPF 如何在内核层面实现安全可视化和控制，是未来的核心技术方向。
2. 多集群与混合云服务网格：探索 Istio 的多集群部署模式 或 Linkerd 的集群镜像。了解服务网格如何跨越多个 Kubernetes 集群甚至异构环境（虚拟机）统一实施安全策略和流量管理，这对构建大规模、高可用的云原生架构至关重要。

---

自检清单

· 是否明确定义了本主题的价值与学习目标？ （本文开篇即阐述其在零信任云原生安全中的支柱地位，并列出5个具体目标）
· 原理部分是否包含一张自解释的Mermaid核心机制图？ （包含一张展示三层安全架构演进的Mermaid时序图）
· 实战部分是否包含一个可运行的、注释详尽的代码片段？ （包含从环境搭建、部署应用到配置网络策略、集成Istio及L7策略的完整命令行和YAML示例）
· 防御部分是否提供了至少一个具体的安全代码示例或配置方案？ （提供了“危险模式”与“安全模式”的部署清单对比，以及分层防御的基线配置YAML示例）
· 是否建立了与知识大纲中其他文章的联系？ （明确指出了前序文章K8S-FND-001，后继文章MESH-SEC-001和K8S-SEC-003）
· 全文是否避免了未定义的术语和模糊表述？ （所有关键术语如CNI、NetworkPolicy、Service Mesh、mTLS、L7均在首次出现时加粗并给出定义或类比）