在容器化部署中，数据库密码、API密钥和证书等敏感信息经常需要注入运行中的容器。最常见的做法是通过环境变量传递，例如在 docker run 命令中使用 -e MYSQL_ROOT_PASSWORD=123456，但这种方式存在严重的安全隐患。环境变量会被记录在容器配置、进程环境以及宿主机日志中，而且构建镜像时若将密码硬编码在 Dockerfile 的 ENV 或 ARG 指令里，密码会永久保留在镜像层中，即使后续删除也无法彻底清除。理解密码在 Docker 生命周期中的流通路径，是实施安全策略的前提。
常见的密码传递方式与安全风险
Docker 运行容器时向内部传递密码通常有三种途径：命令行环境变量、文件挂载以及镜像构建参数。环境变量是最直观的方式，例如 docker run -e DB_PASSWORD=secret postgres。然而，docker inspect 命令可以轻易读取容器的完整配置，其中包括所有环境变量；如果容器编排平台记录了启动命令，密码也会以明文形式出现在日志中。更严重的是，当容器崩溃或调试时，进程的环境块可能被转储到宿主机文件系统，造成凭据泄露。
文件挂载相比环境变量稍好一些，开发者可以将密码写入宿主机的某个文件，再以只读方式挂载到容器内。但文件权限如果设置不当，例如挂载整个 /etc 目录或使用 777 权限，同样会导致密码被其他容器或宿主机用户读取。此外，将密码文件复制进镜像（通过 COPY 指令）则是最差实践，因为镜像层无法删除，即使后续删除文件，密码仍然存在于历史镜像层中，任何拉取过镜像的人都可以通过 docker history 还原。
使用 ARG 构建参数传入密码会带来另一个问题：ARG 值会被记录到镜像的构建元数据中，即使最终镜像没有对应的 ENV，密码也可能通过镜像标签或构建缓存泄露。因此，Docker 官方明确建议不要使用 ARG 传递敏感信息。三种方式的共同缺陷在于：密码以明文形式存在于某一处，且缺乏访问控制和审计机制。
使用 Docker Secrets 保护敏感信息
Docker Swarm 模式提供了专门的 secrets 管理机制，用来解决上述问题。docker secret 命令创建的秘密会被加密存储在集群的 Raft 日志中，只有被授权访问该 secret 的服务节点才会在运行时解密并挂载到容器内。创建 secret 的方式很简单：
echo "MySecretPassword" | docker secret create db_password - docker secret ls docker secret inspect db_password
在 Swarm 服务中使用 secret 时，可以在 docker service create 命令中通过 --secret 参数指定，例如 docker service create --name db --secret db_password mysql:8.0。Docker 会将 secret 以文件形式挂载到容器的 /run/secrets/db_password，该文件权限默认为 0444，内容不会被写入容器配置或日志。容器内应用只需读取该文件即可获取密码，而无需通过环境变量暴露。
对于使用 Docker Compose 的用户，可以在 compose 文件中引用外部 secret。例如下面的配置让 MySQL 从 secret 文件中读取 root 密码：
version: '3.8'
services:
db:
image: mysql:8.0
secrets:
- db_password
environment:
MYSQL_ROOT_PASSWORD_FILE: /run/secrets/db_password
secrets:
db_password:
external: true
这种做法的优势在于：密码不会出现在 docker inspect 输出中，也不会被记录到 Compose 的环境变量里；secret 文件以只读方式挂载，且内容在容器停止后不会保留在宿主机临时目录。不过需要注意的是，Docker Secrets 仅适用于 Swarm 模式，单机 docker run 并不支持该功能。
非 Swarm 环境下的密码注入实践
在没有 Swarm 的单机 Docker 环境中，开发者无法直接使用 docker secret 命令，但仍可以通过一些替代方案来提升密码安全性。最常见的方式是使用只读文件挂载：将密码存放在宿主机上一个权限严格限制的文件中，比如 chmod 600 /etc/app/secrets/db_password，然后通过 -v /etc/app/secrets/db_password:/run/secrets/db_password:ro 挂载到容器。容器内应用读取该文件即可。
另一种做法是使用 Docker Compose 的 env_file 指令加载环境变量，但正如前文所述，环境变量容易泄露，因此只适合非生产环境或低敏感度场景。如果必须使用环境变量，建议配合容器编排平台的加密配置中心，例如 Kubernetes 的 Secret 或 HashiCorp Vault 的 Agent 注入。Vault 可以通过动态生成短期凭据来避免长期密码泄露，其与 Docker 的集成通常是在容器启动时调用 Vault API 获取凭据，而不是提前写入镜像或环境变量。
此外，还可以使用 tmpfs 挂载来存放密码，避免密码落到磁盘。例如 docker run --tmpfs /run/secrets:rw,size=64k ... 将 secret 目录挂载在内存中，容器退出后内存内容自动清除，进一步降低泄露风险。需要注意的是，tmpfs 中的内容在宿主机重启或容器崩溃时不会持久化，但这也意味着应用需要支持从外部重新获取凭据。
密码轮换与安全加固建议
无论采用何种密码注入方式，定期轮换密码都是降低长期风险的关键手段。在 Swarm 中，可以更新 secret 内容并滚动更新服务：docker secret rm db_password 后重新创建同名 secret，再执行 docker service update --force db 让服务重新挂载最新版本。对于非 Swarm 环境，可以使用配置管理工具（如 Ansible 或 Chef）定期替换宿主机上的密码文件并重启相关容器。
安全加固还包括遵循最小权限原则：容器以非 root 用户运行，secret 文件权限设置为 0400 或 0440，并且只在需要的服务中挂载。日志和监控同样重要：确保容器日志不会输出密码，例如数据库连接字符串中的密码使用 ****** 遮蔽；同时启用审计日志记录对 secret 文件的访问行为，及时发现异常读取。
最后，如果密码需要跨主机传输或存储，务必使用加密通道与加密存储。Docker Secrets 在传输和存储时已经加密，但挂载到容器后仍然是明文，因此容器内的文件系统安全性也不容忽视。结合 AppArmor 或 seccomp 限制容器对 /run/secrets 的访问，可以构建纵深防御体系，让密码管理从单点防护走向整体安全。