Kubernetes Ingress Controller流量路径与防火墙配置实战-代码聚汇网

Kubernetes Ingress Controller流量路径与防火墙配置实战

纪环

1. Ingress Controller流量路径与防火墙介入点解析

凌晨三点被告警惊醒的经历，相信不少运维同行都深有体会。那次攻击事件让我彻底搞明白了Ingress Controller流量路径中防火墙的实际作用位置。本文将基于真实生产环境经验，详细拆解从公网请求到Pod的全链路安全拦截机制。

在Kubernetes环境中，Ingress Controller（以Nginx为例）的流量路径会因部署模式不同而产生显著差异，这也直接决定了防火墙规则的有效性。下面我们通过三种典型部署模式来分析防火墙的介入环节。

1.1 NodePort模式下的流量路径

NodePort是最常见的Ingress Controller暴露方式之一。当采用这种模式时，外部流量会经过以下路径：

客户端发起请求到任意Node的NodePort（默认范围30000-32767）
内核netfilter框架的PREROUTING链处理
经过KUBE-SERVICES等Kubernetes管理的iptables规则
转发到FORWARD链（而非INPUT链）
通过CNI插件配置的网络规则到达Pod

关键发现：在NodePort模式下，主机防火墙的INPUT链规则完全不会生效！因为流量最终是转发到Pod，而不是由主机本身处理。

我曾在一个客户环境中遇到这种情况：他们在所有节点上都配置了严格的INPUT链规则，但攻击流量依然畅通无阻。后来通过以下命令确认了问题：

bash复制# 查看FORWARD链的规则和统计
sudo iptables -t filter -L FORWARD -v -n --line-numbers

解决方案是：

在FORWARD链添加防护规则
或者使用NetworkPolicy进行防护
更现代的方案是采用eBPF在更底层进行拦截

1.2 LoadBalancer模式的特殊考量

当使用云服务商的LoadBalancer时，流量路径与NodePort类似，但有几点关键差异：

云厂商的LB通常会对源IP进行SNAT（源地址转换）
部分厂商支持"保留客户端IP"功能
实际到达节点的流量可能来自LB的内部IP

这就导致：

传统的基于源IP的防火墙规则可能失效
需要特别关注X-Forwarded-For等HTTP头部的真实性
云厂商的安全组规则会成为第一道防线

我们在AWS环境中的最佳实践是：

bash复制# 配合AWS安全组使用的iptables规则示例
iptables -A FORWARD -p tcp --dport 80 -m state --state NEW -m recent --set
iptables -A FORWARD -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 60 --hitcount 10 -j DROP

1.3 hostNetwork模式的独特行为

当Ingress Controller使用hostNetwork模式时，情况完全不同：

流量直接进入主机网络命名空间
经过标准的INPUT链处理
绕过了CNI插件管理的网络规则
主机防火墙规则完全生效

这种模式下：

传统的iptables规则可以正常发挥作用
但Kubernetes NetworkPolicy将失效
需要特别注意端口冲突问题

我们曾在一个性能敏感场景中使用这种模式，防火墙配置如下：

bash复制# 针对HTTP流量的基础防护
iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 -j DROP
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --set
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds 10 --hitcount 20 -j DROP

2. 全链路安全防护方案设计

理解了流量路径后，我们需要构建多层防御体系。下面分享我们在生产环境中验证过的方案。

2.1 网络层防护

基础架构层：

云安全组/ACL：限制只允许必要IP访问
节点级iptables：根据部署模式选择INPUT或FORWARD链

Kubernetes层：

bash复制# NetworkPolicy示例：只允许来自特定命名空间的流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress
spec:
  podSelector:
    matchLabels:
      app: nginx-ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          role: external

2.2 应用层防护

Ingress Controller配置：

yaml复制# nginx-config snippet
http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
    server {
        limit_req zone=one burst=20;
    }
}

WAF集成方案：

ModSecurity模块
云厂商提供的WAF服务
开源方案如NAXSI

2.3 监控与响应

建立完善的监控体系：

流量异常检测
规则命中监控
自动阻断机制

我们使用的Prometheus监控规则示例：

yaml复制groups:
- name: ingress-security
  rules:
  - alert: IngressFloodAttack
    expr: rate(nginx_http_requests_total{status=~"4.."}[1m]) > 100
    for: 5m

3. 常见问题与实战排错

在实际运维中，我们积累了大量排错经验，以下是典型场景。

3.1 防火墙规则不生效排查

症状：

配置了DROP规则但攻击依然成功
日志中没有规则命中记录

排查步骤：

确认Ingress Controller部署模式

检查流量实际经过的链

bash复制# 查看规则命中计数
iptables -L -v -n

验证规则顺序是否正确
检查是否有其他规则提前RETURN

典型案例：
某次事故中，我们发现虽然配置了规则，但因为KUBE-FIREWALL链提前RETURN，导致自定义规则失效。解决方案是在KUBE-FIREWALL链前插入规则。

3.2 性能问题诊断

症状：

启用防护后延迟增加
吞吐量下降明显

优化方案：

使用更高效的匹配条件

bash复制# 优化前的慢规则
iptables -A FORWARD -p tcp --dport 80 -m string --string "evil-pattern" --algo bm -j DROP

# 优化后的版本
iptables -A FORWARD -p tcp --dport 80 -m recent --name ATTACKER --rcheck --seconds 3600 -j DROP

考虑将部分规则移到应用层
使用eBPF替代部分iptables功能

3.3 多云环境适配

在不同云环境中，我们发现了这些差异：

AWS：安全组是无状态的，需要显式配置回包规则
GCP：网络负载均衡器会保留客户端IP
Azure：某些SKU的LB会修改TCP时间戳

对应的适配方案：

bash复制# AWS环境特殊规则
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

4. 高级防护技巧

经过多次攻防演练，我们总结了这些进阶防护手段。

4.1 基于地理位置的阻断

使用ipset管理国家IP范围：

bash复制# 创建中国IP集合
ipset create china hash:net
# 下载中国IP段并导入
curl -s http://www.ipdeny.com/ipblocks/data/countries/cn.zone | while read line; do ipset add china $line; done
# 应用规则
iptables -A FORWARD -m set --match-set china src -j DROP

4.2 慢速攻击防护

针对HTTP慢速攻击的特殊防护：

nginx复制# nginx配置
server {
    client_body_timeout 10s;
    client_header_timeout 10s;
    keepalive_timeout 5s 5s;
}

4.3 自动化封禁

集成Fail2ban实现自动封禁：

ini复制# fail2ban配置示例
[nginx-http-flood]
enabled = true
filter = nginx-http-flood
action = iptables-allports[name=nginx_flood, protocol=all]
logpath = /var/log/nginx/access.log
findtime = 60
maxretry = 100
bantime = 3600

在实际生产环境中，我们建议采用分层防御策略，从网络层到应用层构建完整防护体系。不同的部署模式需要不同的防护重点，理解流量路径是配置有效防火墙规则的前提。经过多次真实攻击事件的考验，这套方案已经能够有效防护大多数常见的网络层攻击。