容器云平台防火墙需支持pod动态伸缩、租户隔离与细粒度连接跟踪，nftables是最佳原生方案；推荐inet表管过滤、ip表管nat，避免bridge/netdev表冲突，forward链兜底阻断同节点pod直连，并用set/map实现命名空间级策略与可观测性日志。
容器云平台对防火墙的要求和传统服务器不同：规则要能随 Pod 动态伸缩、避免与 CNI 冲突、隔离租户流量、支持细粒度连接跟踪，同时不能破坏 Kubernetes 的 Service 流量路径。nftables 是目前最适配的原生方案——它不依赖用户态代理、支持原子更新、可嵌入 CNI 插件、且能统一处理 IPv4/IPv6 流量。
容器环境下的表结构设计
推荐使用 inet 协议族统一管理，但 NAT 类规则必须拆到 ip 表（因内核限制不支持 inet + nat 混用）：
- 创建主过滤表：
nft add table inet filter—— 用于 Pod 入口/出口策略、命名空间隔离、连接状态控制 - 创建 NAT 表：
nft add table ip nat—— 仅承载 SNAT（出向地址伪装）、DNAT（NodePort/LoadBalancer 映射），不放任何过滤逻辑 - 避免创建
bridge或netdev表，除非你明确在做主机侧 DDoS 防护或 OVS 卸载，否则易与 CNI 的 ebtables 规则冲突
关键链配置：绕过 kube-proxy 干扰
Kubernetes 默认通过 iptables 或 nftables 模式运行 kube-proxy，它会在 nat 表中大量写入规则。为防止自定义策略被覆盖或执行顺序错乱，应：
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 在
filter表中专注 INPUT/FORWARD/OUTPUT 链，**不碰 nat 表中的 prerouting/output 链** - FORWARD 链开头加一条兜底规则：
nft add rule inet filter forward iifname "cni0" oifname "cni0" drop—— 阻断同节点 Pod 间非 Service 的直连，强制走 kube-proxy 或 CoreDNS - 对 Ingress Controller 所在节点，额外允许宿主机到 NodePort 的访问：
nft add rule inet filter input tcp dport @nodeports accept（@nodeports是预定义端口集合，如{ 30000-32767 }）
租户与命名空间级隔离实现
利用 nftables 原生集合（set）和 map，替代传统 per-pod iptables 规则爆炸问题：
- 按 Namespace 创建 IP 集合：
nft add set inet filter ns-prod { type ipv4_addr\; } - 配合 CNI 的 IPAM 回调，在 Pod 创建时自动注入：
nft add element inet filter ns-prod { 10.244.1.45 } - 在 FORWARD 链中限制跨命名空间通信：
nft add rule inet filter forward ip saddr @ns-prod ip daddr @ns-staging drop - 如需更细粒度（如只允许某 Deployment 访问 DB），可用 map 存储 label selector 匹配结果，由外部控制器同步更新
日志与可观测性落地要点
容器场景下日志不能只靠 log，需结合 conntrack 和时间戳定位真实源头：
- 记录被拒绝的入向连接，并附带原始源 IP（非 SNAT 后）：
nft add rule inet filter input ct state invalid log prefix "DROP_INVALID: " counter drop - 对所有 FORWARD 拒绝规则启用
meta nftrace on，配合nflog工具抓包分析，避免只看到“被 drop”却不知是哪个 Pod 发起 - 用
limit rate 5/minute burst 10控制日志频率，防止高频扫描刷爆磁盘 - 将日志输出到 journald 后，用 Promtail + Loki 做标签化采集，字段包括：
namespace、pod_name、src_ip、dst_port
