Docker容器网络审计日志需从内核层、网络插件层等主动采集，因网络行为不输出到stdout/stderr；四类方法包括：iptables+auditd捕获规则变更、Docker 24.0+内置network-audit日志、CNI插件（Calico/Cilium）策略审计、eBPF流量镜像抓包，核心是回答“谁发起、目标在哪、是否被允许”三大问题。
Docker 容器网络审计日志不是靠 docker logs 或默认日志驱动就能获取的，因为网络行为（如端口绑定、iptables 规则变更、容器间通信、DNS 查询、外连请求）本身不输出到 stdout/stderr。真正可审计的网络活动需从内核层、网络插件层、代理层或流量镜像层主动采集。以下是落地性强、生产可用的四类方法，按优先级和适用场景组织：
用 iptables + auditd 捕获容器网络操作事件
Docker 启动/停止容器时会动态增删 iptables 规则（如 DOCKER-USER、DOCKER-ISOLATION-STAGE-1 链），这些变更可被 auditd 实时捕获：
- 在宿主机启用 auditd 并添加规则：
auditctl -w /sbin/iptables -p x -k docker_iptables auditctl -w /sbin/ip6tables -p x -k docker_ip6tables
- 查看网络策略变更日志：
ausearch -i -k docker_iptables | grep -E "(INSERT|DELETE|ACCEPT|DROP)"
输出含时间戳、执行用户（UID）、调用命令（comm）、目标链名和规则内容，满足等保对“谁改了防火墙”的审计要求。
启用 Docker 内置网络审计（Docker 24.0+）
新版 Docker 支持 --network=host 或自定义 CNI 插件下的细粒度日志，但更直接的是开启 daemon 级网络事件审计：
- 修改
/etc/docker/daemon.json：{ "experimental": true, "audit-log": { "path": "/var/log/docker/network-audit.json", "log-format": "json", "log-level": "info" } } - 重启后，所有
docker network create、docker network connect/disconnect、docker run --network等操作将生成结构化审计条目，字段包括：-
action:"network_create"/"network_connect" -
network_name,container_id,user,remote_addr（若通过 API 调用） -
result:"success"或"failed"
-
部署 CNI 插件日志（如 Calico、Cilium）
若使用 Calico 或 Cilium 作为集群网络插件，它们自带网络策略审计能力：
-
Calico：启用
felix组件的日志级别为info，并配置LogSeverityScreen: INFO，其日志中会记录：- Pod IP 分配与回收
- NetworkPolicy 匹配结果（
policy matched=true/false） - 连接被拒绝时的源/目标 IP、端口、协议
-
Cilium：运行
cilium monitor --type trace可实时抓包级事件；长期审计建议开启--enable-k8s-event-monitor，将 NetworkPolicy 事件同步至 Kubernetes event，并通过 Fluentd 转发至 ELK。
流量镜像 + eBPF 抓包（高保真审计）
对关键业务容器，需审计实际进出流量（非仅连接建立）：
- 使用
bpftrace或cilium monitor抓取特定容器 PID 的 socket 读写：cilium monitor --type trace --related-to <pod-name>
- 或部署
ebpf-exporter，将 TCP 连接建立、DNS 查询、TLS 握手等事件转为 Prometheus 指标，再结合 Grafana 告警（如“某容器在非工作时间访问境外 IP”）。 - 注意：eBPF 方案需内核 ≥5.4，且容器启动时加
--cap-add=SYS_ADMIN（或使用 hostNetwork）。
不复杂但容易忽略——网络审计的关键不在“有没有日志”，而在“日志能否回答三个问题”：谁发起的？目标在哪？是否被策略允许？选一种方法打底，再叠加一到两种做交叉验证，审计链条才算闭环。
