如何记录Kubernetes Pod中执行的所有命令及子命令？

1. 适配 Auditbeat 到 K8s 环境（复用原有工具） #

你之前用的Auditbeat完全可以扩展到K8s场景，核心是通过节点的Linux Audit系统追踪容器内进程：

• 在每个K8s节点上配置auditd规则，针对容器的cgroup路径（比如/sys/fs/cgroup/unified/kubepods/...）追踪execve系统调用——这个调用是所有进程启动的入口，包括交互式shell里执行的子命令（比如bash之后的ifconfig）
• 配置Auditbeat收集节点审计日志，同时开启K8s元数据 enrichment，让日志自动关联对应的Pod名称、命名空间等信息，方便后续溯源
• 注意要确保audit规则覆盖所有容器的cgroup目录，避免遗漏Pod

2. 用 Sysdig 实现细粒度命令链审计 #

Sysdig 天生适配容器环境，能完整捕获容器内的系统调用链：

• 部署Sysdig Agent到所有K8s节点，开启进程审计规则，重点追踪execve调用并记录父进程ID——这样就能把bash和后续执行的ifconfig这类子命令关联成完整的命令链
• 可以自定义过滤规则，只针对特定命名空间或Pod收集日志，减少不必要的资源消耗
• 优势是无需依赖节点的auditd，自身就能穿透容器隔离捕获事件，且日志自带容器和K8s上下文信息

3. 容器运行时原生审计（containerd/CRI-O） #

如果你的集群用containerd或CRI-O作为运行时，可以直接开启它们的审计功能：

• containerd：修改config.toml，启用audit模块并设置audit_level=info，会记录容器内所有进程启动事件，包括子进程
• CRI-O：调整crio.conf开启审计日志，同样能捕获容器内的命令执行动作
• 后续用Filebeat或Fluentd收集运行时审计日志，再结合K8s元数据做关联分析

4. 特定Pod的Sidecar审计方案（小范围场景） #

如果只需要对部分核心Pod做审计，可以注入共享PID命名空间的sidecar：

• 在目标Pod中添加一个sidecar容器，共享主容器的PID命名空间，然后在sidecar中运行strace -p <主容器PID> -e execve或轻量审计工具，实时捕获主容器内的所有命令执行
• 缺点是会增加Pod的资源开销，适合小范围、高优先级的业务Pod审计

内容的提问来源于stack exchange，提问作者Michael Cab