网络微分段与零信任落地：从平面网络到按需互通的隔离架构

南北向（North-South）：外部 ↔ 集群/数据中心（入口防护：WAF/网关）
东西向（East-West）：  集群内服务 ↔ 服务（微分段主场）

攻击场景：攻击者通过南北向入口攻破一个服务，
        东西向流量没有隔离 → 可横向访问数据库/内部 API

安全粒度演进：
  机房/边界（粗） → 子网/VLAN → 主机 → 容器/工作负载（细）
  策略对象：IP 段  → 防火墙   → 标签     → 工作负载身份（SPIFFE）
  ←—— 更可控、更复杂 ——←

第一步：绘制应用依赖图（谁调用谁）
  前端 → 订单服务 → 数据库
  前端 → 用户服务 → 用户数据库

第二步：逐条转换为显式允许规则
  allow 前端 → 订单服务 (HTTP 80)
  allow 订单服务 → 数据库 (TCP 3306)
  allow 前端 → 用户服务 (HTTP 80)
  allow 用户服务 → 用户数据库 (TCP 3306)
  deny 其余全部

# 用 service 地图/可观测性数据自动发现依赖
# 示例：基于网络抓包/审计日志统计服务间调用
kubectl get pods -o wide  # 先看清工作负载
# 生产建议：基于 eBPF/Cilium Hubble 的服务图自动生成依赖

# dependency_graph.py — 从访问日志构建依赖图
def build_dependency_graph(access_logs: list[dict]) -> dict:
    """解析访问日志 (src, dst, port)，构建服务间依赖图。"""
    graph = {}
    for log in access_logs:
        src, dst, port = log["src"], log["dst"], log["port"]
        graph.setdefault(dst, []).append({"from": src, "port": port})
    return graph

def generate_policies_from_graph(graph, default="deny") -> list[dict]:
    """依赖图 → 显式允许策略集（其余默认拒绝）。"""
    return [{"src": e["from"], "dst": dst, "port": e["port"]}
            for dst, edges in graph.items() for e in edges]

# 1. 先立"默认拒绝"基线（每个命名空间）
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: backend
spec:
  podSelector: {}          # 匹配命名空间全部 Pod
  policyTypes: ["Ingress", "Egress"]
  ingress: []              # 拒绝所有入站
  egress: []               # 拒绝所有出站

# 2. 显式放行：前端 → 订单服务
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-orders
  namespace: backend
spec:
  podSelector:
    matchLabels: {app: orders}          # 目标服务
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels: {app: frontend-ns}
          podSelector:
            matchLabels: {app: frontend}
      ports:
        - protocol: TCP
          port: 8080                     # 仅业务端口

# 3. 出站隔离：数据库只允许访问特定 DNS 与 K8s API
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-egress-only
  namespace: data
spec:
  podSelector:
    matchLabels: {app: postgres}
  policyTypes: ["Egress"]
  egress:
    - to:
        - namespaceSelector: {}        # K8s API/DNS 所在
          podSelector:
            matchLabels: {k8s-app: kube-dns}
      ports: [{protocol: UDP, port: 53}, {protocol: TCP, port: 53}]
    # 其余出站默认拒绝 → 即使被攻破也难以外泄数据

# Cilium 的 L7 策略：只允许 GET /api/orders
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: orders-l7-allow
  namespace: backend
spec:
  endpointSelector:
    matchLabels: {app: orders}
  ingress:
    - fromEndpoints:
        - matchLabels: {app: frontend}
      toPorts:
        - ports:
            - port: "8080"
          rules:
            http:
              - method: GET
                path: "/api/orders/**"

mTLS（双向 TLS）：
  客户端 ✓ ✓ 服务端
    │  证书   │
    ├─────────┤  双方都验证对方证书
    │  证书   │
    │  协商密钥 │
    │  加密通信 │
  身份来源：SPIFFE 证书（每个工作负载一个身份）
  身份格式：spiffe://cluster/ns/backend/sa/orders

# PeerAuthentication：强制命名空间内所有流量走 mTLS
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: strict-mtls
  namespace: backend
spec:
  mtls:
    mode: STRICT      # 拒绝非 mTLS 流量（PERMISSIVE 是过渡）

# AuthorizationPolicy：身份级授权（替换 IP 白名单）
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: orders-allow-frontend
  namespace: backend
spec:
  selector:
    matchLabels: {app: orders}
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/frontend/sa/frontend-sa"]
      to:
        - operation:
            methods: ["GET", "POST"]

迁移步骤：
阶段 1 透明加密（PERMISSIVE）：mTLS 开启但不拒绝明文——先建立加密基线
阶段 2 身份可达（STRICT 试点）：高价值命名空间强制 mTLS
阶段 3 全量 STRICT：所有命名空间强制 mTLS
阶段 4 策略收紧：按 AuthorizationPolicy 做身份级授权

监控：确保迁移不破坏业务——观察 5xx 错误率与调用图

SPIFFE 身份格式：
  spiffe://trust-domain/namespace/pod-name

SPIRE 实现：
  Agent 在每个节点验证工作负载 → 签发短期证书（SVID）
  证书自动轮换（分钟级）→ 无静态密钥
  应用通过本地 socket 获取身份证书

# 注册工作负载条目：身份绑定到 k8s 服务账号
apiVersion: spire.spiffe.io/v1alpha1
kind: ClusterSpiffeID
metadata:
  name: orders-spiffe
  namespace: backend
spec:
  spiffeID: "spiffe://cluster/ns/backend/sa/orders-sa"
  podSelector:
    matchLabels: {app: orders}

// Go 应用中获取 SPIFFE 身份
import (
    "context"
    "crypto/tls"
    "github.com/spiffe/go-spiffe/v2/workloadapi"
)

func getSVID(ctx context.Context) (tls.Certificate, error) {
    // 从本地 Agent socket 获取自动轮换的 SVID
    src, err := workloadapi.NewX509Source(ctx, workloadapi.WithClientOptions(
        workloadapi.WithAddr("unix:///run/spire/agent.sock")))
    if err != nil { return tls.Certificate{}, err }
    return src.GetX509Certificate(), nil
}

-- PostgreSQL：以 SPIFFE 身份做访问控制
-- 应用每次连接提供 mTLS 证书（含 SPIFFE 身份）
CREATE ROLE orders_sa LOGIN;
GRANT SELECT, INSERT ON orders TO orders_sa;
-- 认证走 mTLS，授权走数据库角色 —— 不靠客户端 IP

决策：
  · 纯容器 + 想控制复杂度 → Cilium（eBPF 原生、L7 能力）
  · 需要 mTLS + 身份授权 → 服务网格（Istio 全面 / Linkerd 轻量）
  · 混合 VM + 容器 → 云厂商微分段 + CNI 结合
  · 已有服务网格 → 优先用网格策略，避免双栈

第 1 步（基线）：启用可观测性，绘制完整依赖图（1-2 周）
第 2 步（默认拒绝）：关键命名空间立 deny-all（1 周）
第 3 步（显式允许）：按依赖图逐条放行（2-4 周）
第 4 步（验证）：对比放行前后流量，确认无断链
第 5 步（加严）：全命名空间默认拒绝 + 定期策略评审

# 验证：从一个 Pod 测试到目标的连通性
kubectl exec -n frontend deploy/frontend -- \
  curl -sv http://orders.backend.svc:8080/api/orders
# 应看到 TLS 握手 + 200；若 403/超时则检查策略

# policy_test.py — 自动验证策略矩阵
def verify_policy_matrix(allow_pairs, deny_pairs, exec_fn):
    """对期望允许/拒绝的路径逐一验证。"""
    failures = []
    for src, dst in allow_pairs:
        if not exec_fn(src, dst):        # 期望通
            failures.append(f"应允许却不通: {src}→{dst}")
    for src, dst in deny_pairs:
        if exec_fn(src, dst):            # 期望断
            failures.append(f"应拒绝却连通: {src}→{dst}")
    return failures

┌────────────────────────────────────────────────────┐
│ 南北向（外部 → 内）                                 │
│   WAF → API 网关 → 身份验证 → 限流 → 接入应用        │
├────────────────────────────────────────────────────┤
│ 东西向（服务 → 服务）                                │
│   mTLS 加密 + SPIFFE 身份 + 策略授权 + L7 控制       │
├────────────────────────────────────────────────────┤
│ 数据层                                         │
│   工作负载身份访问控制 + 数据加密 + 审计              │
└────────────────────────────────────────────────────┘

# 多集群：统一信任域 + 跨集群身份
# 每个集群的 SPIRE 注册到同一信任域
# Istio 多集群 mesh：mTLS 跨集群工作负载互通，策略统一
trustDomain: cluster.example.com
# 跨集群策略示例：payments 集群的 svc 可访问 orders 集群
# （按 SPIFFE 身份授权，而非集群内 IP）

# segmentation_assessment.py
def assess_segmentation(cluster_api) -> dict:
    """评估微分段覆盖度与有效性。"""
    workloads = cluster_api.list_pods()
    protected = sum(1 for p in workloads if has_network_policy(p))
    coverage = protected / len(workloads)
    # 其他维度：
    mTLS_ratio = mTLS_enabled_services() / total_services()
    default_deny_ns = deny_all_namespaces() / total_namespaces()
    return {
        "policy_coverage": coverage,
        "mtls_ratio": mTLS_ratio,
        "default_deny_ratio": default_deny_ns,
    }

红队演练场景：
  1. 攻破前端 Pod → 尝试横向访问订单/数据库（应被拒绝）
  2. 攻破无策略命名空间的 Pod → 尝试访问高价值服务
  3. 尝试从数据库 Pod 向公网外泄数据（应被出口策略拦截）
  4. 伪造 IP 尝试访问 → 应被身份验证拦截（mTLS）