凭据用文件注入
compose 的 secrets 把敏感内容以文件形式注入容器，默认落在 /run/secrets/ 目录下，应用按路径读取。相比把口令写进环境变量，这种方式不会被 inspect 输出带出、也不会出现在子进程的环境里，改动与轮换只涉及一个文件。单机 compose 场景下它以文件挂载形式生效，集群环境的密钥管理另有机制，语义不完全相同。
基本信息
| 顶层声明 | secrets: 名称: {file: 相对路径} |
|---|---|
| 服务引用 | services.<服务>.secrets: [名称] |
| 容器内位置 | /run/secrets/<名称>（Linux 容器） |
| 适用范围 | 单机与本地开发的凭据注入 |
典型使用场景
- 数据库口令：不写进 compose 环境变量，改从文件读取
- 证书与私钥：以文件形式挂入，避免打进镜像
- 第三方接口密钥：轮换时只改一个文件并重启对应服务
- 本地与测试隔离：真实凭据不入库，仓库里只放占位说明
- 审计可查：注入路径统一，检查容器里是否存在明文散落
声明与读取
声明与读取
services:
api:
image: app/api:1.4.2
secrets:
- db_password # 引用下面的声明
environment:
- DB_PASSWORD_FILE=/run/secrets/db_password # 只传路径，不传值
secrets:
db_password:
file: ./secrets/db_password.txt # 路径相对 compose 文件所在目录
注入方式对照
| 方式 | 可见性 | 主要风险 |
|---|---|---|
| 环境变量 | inspect 与子进程环境可见 | 进程列表、日志与错误上报容易带出 |
| 文件型 secret | 以文件挂载，按需读取 | 应用要改成读文件路径 |
| 写进镜像 | 随镜像分发给所有拉取者 | 相当于公开凭据 |
| 宿主配置文件挂载 | 由宿主文件权限决定 | 属主与权限需单独管理 |
声明里的 file 路径相对 compose 文件所在目录解析，在不同目录执行命令时结果一致，这点比手写挂载路径更稳。
仓库里只提交占位文件与说明，真实内容由部署环节注入；把真实凭据提交进版本库等于永久泄露。
检查是否真的用上了 secret：容器里 cat /run/secrets/名称 能读到内容、而 docker inspect 的环境变量里看不到明文，才算改造到位。