Docker的tmpfs默认可能swap到磁盘，带来敏感数据泄露风险；应通过设置size限制、验证swap状态，并将vm.tmpfs_swappiness=0禁用tmpfs交换，结合noexec/nosuid最小化权限，三者协同实现安全加固。
docker 的 tmpfs 默认允许将不活跃页面交换（swap）到磁盘，这会带来敏感数据泄露风险——即使数据本应只驻留内存，一旦被内核 swap 到磁盘文件（如 /swapfile 或 swap 分区），就可能被未授权访问、快照提取或物理介质恢复。
要阻止敏感内容落入交换分区，关键不是禁用主机 swap（通常不现实），而是让 tmpfs 挂载明确拒绝交换行为。Linux 内核自 4.18 起支持 noexec,nosuid,nodev,mode=...,size=...,nr_inodes=...,uid=...,gid=...,**noatime,strictatime,*** 等选项，但注意：tmpfs 原生不提供 noswap 参数。真正有效的控制方式是组合使用以下两项机制：
使用 mount 选项 size= + mode= 并配合内核参数锁定 swap 行为
tmpfs 是否可 swap，取决于其挂载时是否启用 MS_NOUSER 或受 vm.swappiness 影响，但更直接、可靠的做法是：
-
显式设置
size=上限：防止过度分配导致内核被迫 swap； -
配合
noexec,nosuid,nodev消减攻击面：降低恶意利用机会； - 在挂载后检查是否实际被 swap：确认无 page 被换出。
不过，最根本的加固手段是：
禁用该 tmpfs 实例的 swap 能力（需内核 ≥ 5.13 + CONFIG_TMPFS_SWAP=n）
⚠️ 当前主流发行版（如 Ubuntu 22.04+/RHEL 9+）默认内核已编译禁用 tmpfs swap 功能，但需验证：
# 查看内核是否禁用了 tmpfs swap（返回 0 表示禁用） cat /proc/sys/vm/tmpfs_swappiness 2>/dev/null || echo "not supported"
若输出 0，说明该系统中所有 tmpfs 挂载默认不参与 swap，无需额外操作。
若输出 100（旧内核默认值），则需手动干预：
生产环境推荐的三步加固操作
-
步骤一：强制限制 size，避免内存压力触发 swap
明确指定size=，且值略高于应用峰值使用量（建议预留 20% 余量），例如：--tmpfs /run/secrets:rw,noexec,nosuid,nodev,size=16m
-
步骤二：挂载后验证无 swap 页面
进入容器检查该挂载点是否关联 swap：# 在容器内执行（需 procfs 可读） grep -A10 "tmpfs" /proc/mounts | grep "/run/secrets" # 查看对应 inode 是否出现在 /proc/swaps 或 /sys/fs/cgroup/memory/... 中（正常应无）
-
步骤三：主机侧全局收紧（可选但强烈建议）
在宿主机上永久禁用 tmpfs swap 行为（适用于内核 ≥ 5.13）：# 临时生效 echo 0 > /proc/sys/vm/tmpfs_swappiness # 永久生效（写入 /etc/sysctl.conf） echo "vm.tmpfs_swappiness = 0" >> /etc/sysctl.conf sysctl -p
? 补充说明：
tmpfs数据是否进入 swap，最终由内核 VM 子系统决策。只要tmpfs_swappiness=0，即使内存紧张，内核也会优先回收 tmpfs 页面（而非 swap），确保敏感内容不会落盘。
不推荐的“伪加固”做法
- ❌ 仅依赖
noexec,nosuid：它们防执行和提权，但不防 swap； - ❌ 删除主机 swap 分区：破坏系统稳定性，且无法杜绝 zram/swapfile 等替代方案；
- ❌ 使用
ramfs替代：ramfs不支持size=限制，无内存保护，极易 OOM。
真正安全的 tmpfs 敏感挂载，核心是 可控大小 + 内核级 swap 禁用 + 权限最小化。三者缺一不可。
