容器技术让应用的部署变得空前灵活，但也给安全审计带来了新的挑战。传统物理机或虚拟机上的审计手段，比如直接在宿主机查看登录记录和操作历史，到了容器场景里就变得捉襟见肘：容器生命周期短、文件系统可写层随时可能被丢弃、exec进去的操作不会留下完整的shell历史。一旦出现问题需要追责或者过等保合规检查，运维团队往往拿不出可信的操作证据。这篇文章就来聊聊如何给容器环境搭建一套完整的审计加录屏体系，让每一次进入容器的操作都有据可查、有屏可回。
容器环境审计到底难在哪里
先说清楚问题，才好对症下药。容器审计的第一个难点在于生命周期短暂。一个容器可能只存活几分钟甚至几秒，等安全团队发现异常再去查容器内的日志时，容器早已销毁，可写层数据随之消失。第二个难点是入口多样化：用户可以通过docker exec、kubectl exec、docker attach、API 调用甚至 web 终端等多种方式进入容器，单纯依赖容器内的history文件根本覆盖不了所有路径。
第三个难点是权限提升隐蔽。容器内的root和宿主机的root虽然理论上隔离，但如果容器被授予了privileged权限，或者挂载了docker.sock，容器内的操作就能直接影响宿主机。审计体系必须能够识别这类高危行为，而不是只盯着容器内部。
基于这些特点，一个合理的审计方案应该是分层的：宿主机层负责记录容器生命周期事件和exec调用，容器层负责记录内部文件和进程行为，会话层负责录屏留存终端操作。三层配合，才能形成完整的证据链。
宿主机层：用好auditd和Docker事件流
宿主机是所有容器操作的必经之路，这里的审计日志最有说服力。Linux内核自带的auditd是最可靠的工具，它可以审计所有对docker命令、containerd运行时二进制的调用。下面是一份可以直接使用的审计规则配置：
# /etc/audit/rules.d/docker.rules # 审计docker相关二进制的所有执行 -w /usr/bin/docker -p x -k docker_exec -w /usr/bin/dockerd -p x -k docker_daemon -w /usr/bin/containerd -p x -k containerd # 审计docker.sock的读写，捕获API调用 -w /var/run/docker.sock -p rwxa -k docker_socket # 重新加载规则 auditctl -R /etc/audit/rules.d/docker.rules
规则加载后，任何人在宿主机执行docker命令或者通过API访问docker.sock，都会在/var/log/audit/audit.log中留下记录，包含执行用户、进程ID、命令参数等关键信息。这些日志建议通过rsyslog或Filebeat实时外送到日志中心，避免宿主机本身被攻破后日志被篡改。
除了auditd，Docker自身的事件流也值得采集。执行docker events --since 24h --filter type=container可以拿到容器创建、启动、销毁、exec等事件的实时流。把这条事件流接到日志系统里，配合auditd的日志做交叉验证，就能回答“谁在什么时间对哪个容器做了什么”这个核心问题。
容器层：记录文件变更与进程行为
容器内部的行为审计可以从两个角度入手。第一个角度是文件系统差异比对。Docker提供了docker diff命令，能列出容器自启动以来可写层的所有变更：
# 查看容器文件系统变更 # C表示改动，A表示新增，D表示删除 docker diff my_container # 结合定时任务，每小时留存一次快照 docker diff my_container >> /var/log/container_diff_$(date +%F_%H).log
这种方式实现简单，适合作为基线监控，但缺点是只能看到结果，看不到过程——你不知道文件是被哪条命令改掉的。要看到过程，需要在容器镜像里预置auditd或sysdig等工具。以sysdig为例，它的falco规则引擎可以直接识别容器内的异常行为，比如提权、修改passwd文件、启动反弹shell等：
# 在宿主机运行sysdig，监控指定容器的文件写入 sysdig -pc -M 1000 container.name=my_container and evt.type=openat and evt.is_open_write=true # 用falco检测容器内的提权行为 falco | grep "container"
sysdig的关键优势在于它工作在宿主机内核层，容器里不需要装任何Agent，对性能的影响也相对可控。对于生产环境，推荐把falco作为常驻服务运行，它的告警可以直接对接SIEM平台。
会话层：终端录屏与操作回放
审计日志再详细，也不如一段录屏直观。所谓容器录屏，并不是真的录制画面，而是记录终端会话的全部输入输出流，之后可以像放电影一样回放。Linux下最经典的工具是ttyrec和asciinema。以asciinema为例，可以把它包装成强制入口，所有进入容器的操作都必须经过录制：
# 安装asciinema pip3 install asciinema # 录制一次容器内的交互会话 asciinema rec /var/log/record/docker_exec_$(date +%F_%H%M%S).cast -- docker exec -it my_container bash # 回放录制的会话 asciinema play /var/log/record/docker_exec_20240101_103000.cast
这种做法的好处是零侵入且证据完整：录制文件是纯文本格式，体积小，还包含时间戳，回放时可以加速、暂停、定位到任意时刻。配合script命令也能实现类似效果：script -t 2>time.log -a session.log记录时间流和内容流，之后用scriptreplay time.log session.log回放。
更工程化的做法是把录屏集成到跳板机或者web终端里。比如基于WebSSH自建的运维入口，在WebSocket建立连接时自动fork出asciinema进程，会话结束时把录制文件连同用户名、目标容器ID一起写入对象存储。这样即使用户通过浏览器操作，也能留下完整的录屏记录。录制文件要设置只有审计团队可读的权限，防止用户自己删除证据。
日志存储与合规落地建议
审计体系跑起来之后，日志的存储和管理同样重要。这里有几条实践经验值得参考。
第一，日志必须外送且不可篡改。无论是auditd日志还是录屏文件，都应该实时转发到独立的日志服务器或对象存储，本地只做临时缓冲。日志保留周期要根据合规要求确定，等保三级一般要求日志留存不少于六个月。
第二，审计系统自身要隔离权限。执行审计采集的进程应该用独立账号运行，业务运维人员无权修改审计配置和删除日志，否则审计就成了形式主义。
第三，定期做回放演练。审计体系搭好后不要束之高阁，每季度抽几次真实的录屏回放和日志检索演练，验证整条链路是否真的能还原一次操作的全过程。演练中发现的盲区，比如某个入口漏了录制，要及时补上。
容器化审计与录屏并不是某个单一工具能解决的问题，它本质上是宿主机、容器、会话三层证据链的构建。把auditd的内核级日志、sysdig的实时行为监控和asciinema的会话录制组合起来，再配上规范的外送存储和权限管理，就能让容器环境的每一次操作都经得起追溯。如果你的团队正面临合规检查或者安全事故频发的困扰，不妨按这个思路逐步落地，先从会话录屏做起，见效最快。