overlay2本身不提供敏感数据保护，安全依赖上层策略：启用--read-only、tmpfs挂载/run/secrets、用户命名空间映射，并严禁密钥入镜像，运行时通过secret或加密卷注入。
存储驱动本身不提供敏感数据保护能力，它只负责镜像层和容器文件系统的组织方式。真正实现安全存放，靠的是在存储驱动之上叠加访问控制、运行时隔离和加密策略——overlay2 是推荐基础，但安全不来自驱动本身，而来自你如何用它。
选对驱动是前提，不是终点
Overlay2 是当前 Linux 主流发行版默认且最成熟的存储驱动，支持高效分层、copy-on-write 和细粒度的 mount 选项控制。它本身不加密、不鉴权，但提供了关键支撑：
- 支持
--read-only启动参数，让整个容器根文件系统不可写，阻断运行时篡改或恶意写入 - 允许对特定路径（如
/run/secrets）单独挂载 tmpfs，内存级临时存储，重启即销毁 - 与用户命名空间（
--userns-remap）配合良好，能将容器内 UID 映射为宿主机上无权限的普通用户，限制对底层存储目录的直接访问
敏感数据绝不进镜像层
这是最常被忽略的安全红线：任何密钥、证书、配置文件都不能通过 COPY 或 ADD 进入镜像。否则，镜像一旦分发或导出，敏感信息就永久暴露。
- 严格使用
.dockerignore排除.env、secrets/、*.pem、config/*.yaml等含密路径 - 采用多阶段构建：构建阶段处理源码和依赖，运行阶段仅
COPY --from=builder编译产物（如二进制、dist 目录），完全跳过配置和密钥 - 禁用
docker build --build-arg传密钥——build-args 会保留在镜像历史中，docker history可直接查看
运行时挂载：让数据“活”在隔离路径
敏感数据应在容器启动时注入，而非打包进镜像。核心是利用 Docker 的挂载机制，在 overlay2 文件系统之上建立受控通道：
-
Swarm 场景：用
docker secret create创建 Secret，服务启动时以--secret source=mykey,target=apikey,mode=0400挂载到/run/secrets/apikey。该路径由 tmpfs 支持，内容加密存于 Raft 日志，容器内只读、不落盘、不进镜像层 -
单机场景：用
docker run --tmpfs /run/secrets:rw,noexec,nosuid,size=8m创建内存挂载点，再通过初始化脚本把从 Vault 或 host-mounted 加密卷解密后的密钥写入其中；确保应用以O_RDONLY打开，并校验文件权限 -
持久化敏感数据（如数据库加密密钥）：不建议存容器内。应使用宿主机端 VeraCrypt 卷或 LUKS 加密块设备，再以
-v /mnt/encrypted:/keys:ro方式只读挂载。Docker 不参与解密，只传递已解密后的文件句柄
加固底层存储目录权限
即使数据不进镜像，Docker 的本地存储目录（默认 /var/lib/docker）若被未授权访问，仍可能泄露镜像元数据或容器运行时状态：
- 启用用户命名空间重映射：
dockerd --userns-remap=default，使容器内 root（UID 0）映射为宿主机上非特权用户，无法直接读写/var/lib/docker下的 overlay2 子目录 - 设置
/var/lib/docker所在分区为noexec,nosuid挂载选项，防止执行任意代码或提权操作 - 定期清理不用的镜像和悬空层：
docker system prune -a --volumes，减少攻击面
