容器与Kubernetes安全第05页：网络隔离与服务网格安全

01 · Pod网络模型与CNI选型

容器网络接口（CNI）插件负责为Pod分配IP并实现跨节点通信。关键认知：Kubernetes API本身不实施任何网络策略——NetworkPolicy资源只是声明，实际执行完全由CNI决定。选错CNI，等于集群网络裸奔。

02 · NetworkPolicy深度解析

2.1 语义基础：默认全通，策略以Pod为粒度叠加

NetworkPolicy按namespace+Pod选择器（podSelector）生效；一个Pod被任一policy选中即进入"仅放行白名单"模式：至少一条入站policy选中→入站白名单化；至少一条出站policy选中→出站白名单化。这是"默认拒绝"架构的实现机制。

# 默认拒绝（某namespace内全部Pod的入站）
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes: [Ingress]
---
# 精确放行：只允许frontend访问backend的8080
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector: { matchLabels: { app: backend } }
  policyTypes: [Ingress]
  ingress:
  - from:
    - podSelector: { matchLabels: { app: frontend } }
    ports: [{ protocol: TCP, port: 8080 }]

2.2 微分段参考架构（模式库）

• IPBlock陷阱：podSelector优先于ipBlock语义中的"集群内IP"理解；CNI实现差异需实测。
• 策略运营：先用Cilium Hubble/Calico日志观测真实流量，再生成白名单（"观测→建模→强制执行"三步），避免拍脑袋策略造成业务中断。

03 · 入口流量安全

• 暴露面最小化：NodePort/LoadBalancer型Service逐一直接暴露是端口蔓延之源；统一入口（Ingress Controller / Gateway API）+集中WAF/限流/鉴权为推荐架构。
• Gateway API（v1.0，2023年10月）：以Gateway、HTTPRoute等资源将"基础设施"与"路由规则"角色分离，多团队共享网关时的策略冲突更少；安全上支持更细粒度的HTTPS/TLS策略与后端引用校验（ReferenceGrant）。
• CVE-2020-8554的教训：Service ExternalIP可被劫持用于集群内MITM（详见第2页档案）。除升级修复版本外，应：限制RBAC中创建/patch带ExternalIP或LoadBalancer IP的Service权限；网络层阻断指向链路本地/元数据地址段（169.254.0.0/16）的服务转发。
• 入口基线：TLS强制（最低TLS1.2）、证书自动轮换（cert-manager）、请求体大小/速率限制、控制器自身以高权限运行时隔离（其持有全集群Ingress配置的写权限）。

04 · 集群DNS安全

CoreDNS是集群服务发现的中枢，同时是被严重低估的攻防面：攻击者既可通过DNS隧道外传数据，也可通过投毒劫持服务发现。

• DNS隧道与C2：长域名TXT查询、异常查询频率是可观测信号；出方向53端口仅放行经企业DNS的解析链，阻断Pod直连公网DNS。
• NodeLocal DNSCache：节点级缓存降低CoreDNS负载与DNSError概率，同时减少跨节点DNS投毒面。
• dnsPolicy基线：默认ClusterFirst；对外部域名解析强制经企业安全DNS（转发到具备威胁情报过滤的解析器）；禁用Pod自定义dnsConfig指向外部公共DNS。
• 可观测：CoreDNS日志+查询模式基线（如某Pod首次出现TXT查询大量子域）；DNS查询指标接入SIEM。

05 · 服务网格安全

服务网格（Service Mesh）以Sidecar（或节点级代理）接管服务间通信，为东西向安全提供两项原生能力：工作负载身份（SPIFFE/SPIRE风格的证书身份）与默认mTLS加密，使"零信任"从口号变成默认配置。

5.1 主流方案安全特性对比

5.2 网格落地安全要点

• mTLS模式分级启用：按namespace从PERMISSIVE（兼容明文）灰度至STRICT，全量监控明文残留后再强制；遗留明文端点即明文漏洞。
• 授权策略最小化：默认拒绝（ALLOW策略白名单化），以"身份到身份+方法/路径"四元组表达；拒绝"全部允许"的长期存在。
• 入口与出口网关：东西向加密不覆盖南北向——入口仍走Gateway+WAF；出口经egress网关统一审计（与子课题01的SSE/CASB协同）。
• 网格自身即攻击面：控制面（istiod）证书签发能力=集群王冠；其暴露面、RBAC与升级SLA按控制面等级防护（第2页标准）。
• ambient模式的边界：无Sidecar降低资源开销，但L7能力依赖waypoint代理部署，评估其覆盖度再决定灰度范围。

5.3 网格CA与证书治理要点

• 根证书（root CA）离线保管：网格根密钥应离线生成、分片保管并登记轮换计划；根证书泄露等于整个网格身份体系失守。
• 工作负载证书短TTL：服务网格工作负载证书默认约24小时有效期并自动轮换——不要为"省事"调长；长TTL扩大泄露窗口。
• 企业CA集成：通过chained CA（中间CA）将网格CA挂接企业PKI，满足审计与合规对证书来源一致性的要求；南北向流量仍以企业证书终结。
• 证书可观测：监控证书签发速率与失败率——签发异常突增可能是身份滥用信号；轮换失败存量应在告警中清零。

06 · eBPF网络一体化方案

eBPF将网络策略执行从iptables规则链下沉到内核可编程路径，带来三项安全运营价值：万级Pod规模下的策略性能、原生L7策略与可观测（Hubble流量拓扑与策略命中计数）、以及与运行时检测（Tetragon，第4页）共享同一数据面。

本节参考来源（第5页）