必须用tmpfs而非volume或bind mount，因其天然驻留内存、不落盘、禁swap，满足审计录像不可持久化、强隔离、自动归零三大安全要求。
用 tmpfs 为容器化堡垒机提供“阅后即焚”的审计录像空间，核心思路是：把录像临时写入内存文件系统，确保内容不落盘、不残留、生命周期与容器严格对齐——录完即存于 ram，容器停则全清，连 swap 都可规避。
为什么必须用 tmpfs 而不是 volume 或 bind mount
堡垒机的审计录像属于高敏临时数据：它需满足三个硬性要求——不可持久化（防磁盘残留泄露）、强隔离性（不能被其他容器或宿主机进程意外访问）、自动归零（容器重启/崩溃后不留痕迹）。Volume 和 bind mount 都会将录像写入磁盘，哪怕加了权限控制，仍存在取证风险；而 tmpfs 天然只驻留内存，关机断电即失，且默认不启用 swap（可显式禁用），从根源上切断数据落地可能。
关键配置：挂载路径、大小限制与安全选项
启动堡垒机容器时，必须显式挂载 tmpfs 到录像存储目录，并严格约束资源：
Multi-Brain Protocol
下载
一款AI工具，主要用于在主代理响应前，并行运行Kimi K2.5和GPT 5.3 Codex，注入双方观点以增强认知多样性，适合需要提升相关任务效率的用户。
-
指定挂载点与 size：例如
--tmpfs /var/log/audit-video:size=2g,uid=1001,gid=1001。size 必须设——未设则可能吃光宿主机内存导致 OOM；单位用小写g/m，避免因G解析失败引发写入错误 -
禁用执行与特权位：追加
noexec,nosuid,nodev。录像只是二进制 blob，绝不允许在该路径下执行任何程序，也禁止 setuid/setgid 提权行为 -
权限收紧：通过
uid/gid将挂载目录属主设为堡垒机专用运行用户（如bastion），避免 root 写入后被其他进程读取
录像流转设计：从录制到销毁的闭环
堡垒机本身不直接管理“销毁”，而是依赖 tmpfs 的天然语义实现自动清理：
- 录像进程（如 ffmpeg 或自研录屏模块）将视频帧持续写入
/var/log/audit-video/session-abc.mp4 - 回放服务（如 Web 控制台）通过 HTTP 流式读取该文件——全程走 page cache，无磁盘 I/O
- 用户关闭会话或主动结束录像，文件句柄关闭；容器正常退出时，整个 tmpfs 挂载点连同所有文件被内核立即释放
- 若容器异常崩溃，Kubernetes/Docker 重建 Pod 时，新容器挂载的是全新 tmpfs 实例，旧录像彻底不可恢复
增强可靠性：配合 Vault 动态注入播放密钥（可选）
若录像需加密存储（如 AES-GCM），密钥不应硬编码或存于镜像。可复用 Vault Agent 边车模式：
- Vault Agent 启动后认证并拉取一次性会话密钥，写入
/dev/shm/audit-key（同样挂载为 tmpfs） - 堡垒机主容器通过内存文件读取密钥，解密后实时流式播放
- 密钥文件与录像文件共处同一内存挂载点，生命周期完全同步，无需额外清理逻辑
