容器网络策略<\/strong><\/p>

基本概念与核心问题<\/strong>
容器网络策略是一种声明式的、基于规则的安全机制，用于控制容器化工作负载（Pods）之间的网络通信。在一个共享的集群网络环境中（例如 Kubernetes 集群），默认情况下，Pod 之间通常可以自由通信，这遵循“允许任何”的默认安全模型。这带来了显著的安全风险，即一个被攻破的 Pod 可能成为横向移动的跳板，攻击集群内的其他服务。容器网络策略的核心目标就是实施“最小权限原则”，精确控制哪些 Pod 能与其他 Pod 通信，以及能进行何种通信（指定协议、端口），从而在网络上建立逻辑隔离。<\/p> <\/li>

工作原理与核心组件<\/strong>
网络策略并非由容器运行时或操作系统防火墙直接实现，而是由容器网络插件（CNI Plugin）或服务网格的数据平面配合策略控制器来强制执行的。以 Kubernetes 原生的 NetworkPolicy<\/code> 资源为例：<\/p>
策略控制器<\/strong>：通常是集群网络方案的一部分（如 Calico 的 Typha、Cilium 的 Operator），负责监视和接收用户定义的 NetworkPolicy<\/code> 资源。<\/li> 策略执行点<\/strong>：通常集成在 CNI 插件的数据平面中（如 Calico 的 Felix 代理、Cilium 的 eBPF 程序）。控制器将策略规则下发到各个节点上的执行点，执行点将这些规则转换为节点内核层面的具体规则（如 iptables 规则、eBPF 过滤器），对进出 Pod 网络接口的数据包进行允许或拒绝操作。<\/li> 选择器模型<\/strong>：策略通过“选择器”来定义作用对象。podSelector<\/code> 选择本策略要保护的 Pod（入方向规则的目标或出方向规则的源），namespaceSelector<\/code> 可以选择整个命名空间，在 ingress<\/code>（入站）和 egress<\/code>（出站）规则中，再通过 from<\/code> 和 to<\/code> 字段，结合 podSelector<\/code>、namespaceSelector<\/code> 甚至 ipBlock<\/code>（IP CIDR 块）来定义被允许的通信对端。<\/li> <\/ul> <\/li> 关键规则与策略定义<\/strong> 一个 NetworkPolicy<\/code> 资源主要定义以下部分：<\/p> 策略目标<\/strong>：通过 spec.podSelector<\/code> 指定该策略应用于哪些 Pod。留空则选择该命名空间下的所有 Pod。<\/li> 策略类型<\/strong>：spec.policyTypes<\/code> 字段，可以是 Ingress<\/code>、Egress<\/code> 或两者皆有，指明该策略是控制入站流量、出站流量还是双向控制。<\/li> 入站规则<\/strong>：spec.ingress<\/code> 是一个规则列表。每条规则可以在 from<\/code> 来源中指定允许的 Pod、命名空间或 IP 段，在 ports<\/code> 中指定允许的协议和端口号。满足 from<\/code> 和 ports<\/code> 条件的流量才被允许进入目标 Pod。<\/li> 出站规则<\/strong>：spec.egress<\/code> 是一个规则列表。每条规则可以在 to<\/code> 目标中指定允许访问的 Pod、命名空间、IP 段，在 ports<\/code> 中指定允许的协议和端口号。满足 to<\/code> 和 ports<\/code> 条件的流量才被允许从目标 Pod 发出。<\/li> 默认拒绝<\/strong>：一旦为一个 Pod 或命名空间创建了任何 NetworkPolicy<\/code> 并选择了它，所有未被该策略明确允许的流量（对应策略类型方向）将被默认拒绝。这是从“允许任何”转变为“拒绝所有，除非明确允许”的关键。<\/li> <\/ul> <\/li> 典型应用场景与实践模式<\/strong><\/p> 命名空间隔离<\/strong>：阻止不同命名空间（如 production<\/code> 和 development<\/code>）的 Pod 之间相互访问，除非业务必需。<\/li> 应用分层隔离<\/strong>：例如，只允许来自“前端”服务的流量访问“后端”服务的特定端口（如 8080），并且阻止“后端”服务访问数据库以外的任何外部地址。<\/li> 数据库访问控制<\/strong>：定义一个策略，仅允许来自特定命名空间中“应用”Pod 的流量访问数据库 Pod 的特定端口（如 3306），阻止所有其他访问，包括集群内部其他组件和互联网的直接访问。<\/li> 出口到公网控制<\/strong>：通过 egress<\/code> 规则和 ipBlock<\/code>，限制 Pod 只能访问特定的外部 API 端点或软件仓库，防止数据外泄或恶意下载。<\/li> <\/ul> <\/li> 高级主题与注意事项<\/strong><\/p> 策略依赖与顺序<\/strong>：多个网络策略可以同时应用于同一个 Pod，结果是这些策略规则的叠加（并集）。不同的 CNI 实现可能对规则评估顺序有细微差异，但通常最终效果是“任何策略允许即允许”。<\/li> 网络插件兼容性<\/strong>：并非所有网络解决方案都支持 Kubernetes NetworkPolicy<\/code>。在部署策略前，需确认集群的 CNI 插件（如 Calico, Cilium, Weave Net, Antrea 等）完整支持该 API。不同插件在功能和性能（尤其是大规模策略下）上存在差异。<\/li> DNS 依赖<\/strong>：出站策略可能影响 Pod 的 DNS 解析。通常需要添加一条允许 Pod 访问 kube-dns\/coredns 服务（通常是 UDP\/TCP 53 端口）的 egress<\/code> 规则，否则基于服务名的通信将失败。<\/li> 与服务网格的协同<\/strong>：在网络策略（L3\/L4 层）之上，可以叠加服务网格（如 Istio）的授权策略（L7 层），实现从网络连接到应用协议（如 HTTP\/gRPC 方法、路径）的纵深防御。两者可以互补，网络策略作为基础网络隔离，服务网格策略进行更细粒度的应用层控制。<\/li> <\/ul> <\/li> <\/ol>