CentOS服务器容器网络策略隔离业务应用，本质上解决的是同一台宿主机上多租户或多业务容器之间的流量可见性与访问控制问题。很多团队在部署完Docker或Podman后，默认把所有容器扔进同一个bridge网络，容器之间通过IP或容器名就能互相访问，这在生产环境里属于高风险做法。一旦某个业务容器被入侵，攻击者可以横向探测同网段内的数据库、缓存、内部API等所有服务，网络策略隔离就是要在这一层把横向移动的路径切断。

先确认基础网络模型与隔离边界

在CentOS 7/8/9上，容器运行时的主流选择是Docker CE、Podman或者containerd配合CRI。无论用哪种，默认的bridge网络只提供NAT出网能力，不提供容器间的访问控制。也就是说，同一个bridge下的容器默认互通，这是内核bridge转发行为决定的，不是容器引擎的额外配置。要改变这一点，必须引入网络策略层。对于Docker，可以通过自定义网络配合iptables规则实现；对于Podman，可以使用CNI插件或Netavark；对于Kubernetes场景，则直接使用NetworkPolicy资源配合CNI插件，如Calico、Cilium、Weave Net等。

隔离的第一步是明确哪些业务属于同一信任域。例如，Web前端容器只应该被网关或负载均衡访问，它需要访问后端的API容器；API容器需要访问数据库和缓存；数据库容器不应该被除API和运维跳板之外的任何容器访问。把这些访问关系画成一张简单的流量矩阵，再决定网络策略怎么写。不要一上来就写规则，否则很容易出现“全放通”或“全拒绝”的极端，导致业务不通或隔离形同虚设。

Docker场景下的iptables策略落地

在纯Docker环境中，最直接的办法是给每个业务组创建独立的自定义bridge网络，然后通过宿主机iptables的FORWARD链控制跨网络访问。例如，创建三个网络：web-net、app-net、db-net。Web容器接入web-net，API容器同时接入web-net和app-net，数据库容器只接入db-net，API容器也接入db-net。这样通过控制容器接入的网络，天然形成了分段。但仅靠分段还不够，因为如果某个容器同时接入两个网络，它就成了两个网络之间的路由节点，攻击者如果拿下这个容器，仍然可以跨段访问。

更严格的做法是在宿主机上写iptables规则，按容器IP或网段做精确的放行与拒绝。比如只允许web-net的容器访问app-net中API容器的8080端口，其余全部DROP。下面是一个示例规则：

# 允许web-net访问app-net的8080端口
iptables -I FORWARD -s 172.20.0.0/24 -d 172.21.0.0/24 -p tcp --dport 8080 -j ACCEPT

# 拒绝web-net访问app-net的其他端口
iptables -I FORWARD -s 172.20.0.0/24 -d 172.21.0.0/24 -j DROP

# 允许app-net访问db-net的3306端口
iptables -I FORWARD -s 172.21.0.0/24 -d 172.22.0.0/24 -p tcp --dport 3306 -j ACCEPT

# 拒绝app-net访问db-net的其他端口
iptables -I FORWARD -s 172.21.0.0/24 -d 172.22.0.0/24 -j DROP

# 默认拒绝所有跨网络转发
iptables -P FORWARD DROP

注意，直接修改宿主机iptables的FORWARD链会影响所有容器流量，包括出网流量。Docker本身会在启动时写入大量iptables规则，手动插入规则时要确保顺序正确，否则可能把Docker自己的NAT规则覆盖掉。建议使用iptables-save备份现有规则，再逐步添加，并测试业务连通性。另外，容器重启后IP可能变化，所以基于IP的规则不适合动态扩缩容的场景，更适合固定IP或固定网段的部署方式。

Podman与CNI网络策略

CentOS 8/9默认推荐Podman，Podman的rootless模式在安全隔离上比Docker更有优势，但网络策略配置思路类似。Podman使用CNI插件管理网络，可以在/etc/cni/net.d/下编写自定义网络配置。要实现容器间的访问控制，可以借助CNI的防火墙插件，例如firewall插件或portmap插件配合iptables。更现代的做法是使用Netavark，它支持更灵活的网络配置和防火墙规则。

一个常见的Podman网络隔离方案是：为每个业务创建独立的网络，然后用podman network create命令指定子网和网关，再通过podman run --network指定容器接入的网络。跨网络访问默认被内核转发允许，所以还需要在宿主机上写iptables规则。与Docker不同的是，Podman rootless模式下iptables规则在用户命名空间内生效，不会影响宿主机全局规则，这在一定程度上降低了误操作风险，但也意味着规则管理更分散。

如果业务规模较大，建议直接上Kubernetes。在K8s中，NetworkPolicy是标准的网络隔离手段，它通过标签选择器定义允许的入站和出站流量。CentOS作为K8s节点时，需要安装支持NetworkPolicy的CNI插件。Calico是最常见的选择，它使用iptables或eBPF实现策略，性能稳定，文档丰富。下面是一个典型的NetworkPolicy示例，只允许带有app=web标签的Pod访问带有app=api标签的Pod的8080端口：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-from-web
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: web
    ports:
    - protocol: TCP
      port: 8080

这个策略默认拒绝所有其他入站流量，包括同命名空间内的其他Pod。K8s的NetworkPolicy是白名单模型，没有匹配到规则的流量全部拒绝，这与iptables的黑名单模型有本质区别。白名单模型更安全，但配置时要覆盖所有合法流量，否则业务会中断。

策略隔离中的常见坑与应对

第一个坑是DNS流量被误伤。很多团队在写拒绝规则时只考虑了业务端口，忘了容器还需要访问DNS服务器。如果默认拒绝所有出站流量，容器内解析域名会失败，导致业务异常。解决办法是显式放行UDP 53到DNS服务器，或者在容器内配置DNS缓存。

第二个坑是健康检查流量被阻断。容器编排系统或负载均衡器通常通过HTTP或TCP探针检查容器健康状态，这些探针流量可能来自宿主机或外部网络。如果策略只允许容器间流量，健康检查会失败，容器被反复重启。需要把健康检查来源IP或网段加入放行规则。

第三个坑是日志采集和监控Agent的流量。生产环境通常有Filebeat、Prometheus Node Exporter、APM Agent等组件，它们需要访问容器或宿主机端口。网络策略必须为这些基础设施组件预留通道，否则监控数据中断，排障时两眼一抹黑。

第四个坑是容器IP变化导致规则失效。在Docker或Podman中，容器重启后IP可能改变，基于IP的iptables规则会失效。解决办法是使用固定IP、使用容器名解析（需要自定义DNS）、或者迁移到K8s使用标签选择器。

基于eBPF的现代隔离思路

对于CentOS 8/9上内核版本较新的系统，可以考虑使用eBPF技术实现更细粒度的网络策略。Cilium是这方面的代表，它不依赖iptables，而是通过eBPF程序在内核中直接处理数据包，性能更好，策略表达能力更强。Cilium支持L3/L4的IP和端口控制，也支持L7的HTTP、gRPC等协议级别的访问控制。例如，可以写一条策略只允许GET /api/v1/health，拒绝POST /admin。这种细粒度控制在传统iptables里很难实现。

不过eBPF方案对内核版本有要求，CentOS 7默认内核较老，需要升级到较新的内核才能稳定运行Cilium。CentOS 8/9的内核版本基本满足要求。如果团队有内核升级能力，且业务对网络性能敏感，Cilium是值得投入的方向。但要注意，eBPF的调试门槛比iptables高，出问题时需要理解BPF程序加载和maps机制。

策略验证与持续审计

网络策略配置完成后，不能只靠“感觉”判断隔离是否生效。需要做实际的连通性测试，从每个业务容器内主动发起连接，验证允许的流量通、拒绝的流量不通。可以使用nc、curl、telnet等工具模拟访问。同时，在宿主机上通过iptables -L -v -n查看规则匹配计数，确认规则确实被命中，而不是形同虚设。

生产环境中，网络策略应该纳入版本管理和审计流程。每次修改策略都要记录变更原因、影响范围和回滚方案。定期审查现有策略，清理不再需要的规则，避免规则堆积导致性能下降或出现意外放行。对于K8s环境，可以使用工具自动发现未受NetworkPolicy保护的Pod，及时补齐策略。

最后要强调的是，网络策略隔离只是纵深防御的一层，不能替代应用层鉴权、容器镜像安全、运行时安全等其他措施。正确的做法是网络策略与身份认证、最小权限、漏洞管理结合起来，形成完整的容器安全体系。在CentOS服务器上做容器网络隔离，核心是理解流量路径、选择合适的策略执行点、持续验证和审计，而不是简单套用模板。