容器化部署虽然提升了交付效率，但密钥管理一直是个棘手的环节。不少团队还停留在把数据库密码写进 Dockerfile、塞进镜像环境变量或者直接打进配置文件的阶段，这种做法看似省事，实际上给生产环境埋下了严重的安全隐患。Docker 镜像分层存储意味着即使后续删除敏感文件，历史层中仍然可以还原出明文；通过 docker inspect 或 docker exec 查看环境变量，也能轻易获取到数据库口令。要解决这些问题，需要一套专门的密钥管理系统介入，让容器在启动时、运行中动态获取短期凭据，而不是长期持有静态密码。HashiCorp Vault 作为集中式秘密管理工具，可以与 Docker 生态很好地协同工作，从认证、授权、签发到吊销形成完整闭环。
理解 Docker 自身的限制之后，就可以规划一套可持续运维的集成方案，核心思路是让容器不再直接接触根令牌或长期密码，而是通过代理或入口逻辑向 Vault 请求短期动态凭据。
为什么 Docker 原生环境变量不适合传递敏感凭据？
很多入门级部署习惯在 docker-compose.yml 里直接写死 MYSQL_ROOT_PASSWORD 或 API_KEY，或者通过构建参数把密码写进镜像。这样做的问题在于：镜像一旦被推送到仓库，任何人都可以拉取镜像并逐层解包，历史层中的密码无法真正清除。即便使用多阶段构建，只要某个较早阶段包含了敏感信息，最终镜像中虽然看不到，但缓存和构建历史中依然存在痕迹。
环境变量同样不够安全。运行中的容器可以通过 docker inspect 或进入容器执行 env 来查看所有环境变量，而且很多监控工具、日志采集器会把容器环境信息上报到中央系统，导致密钥意外进入日志或监控数据。此外，环境变量只能在容器启动时设置，无法在运行过程中自动轮换，一旦泄露就必须重新启动容器才能更新，这在大规模集群中非常低效。
更关键的是，Docker 原生没有租约或过期机制，密码一旦给出就永久有效，做不到按需签发、到期自动失效。因此，需要借助 Vault 这样的外部系统来生成短生命周期的动态凭据，容器每次通过身份认证后拿到只属于自己的临时口令，即使泄露也能在租约到期后自动失效。
基于 AppRole 的 Vault 认证与动态凭据注入
AppRole 是 Vault 为机器身份设计的一种认证方式，特别适合容器、CI/CD 等非人工场景。它通过一对 role_id 和 secret_id 来确认应用身份。role_id 类似于用户名，可以公开分发给容器编排系统；secret_id 类似于密码，需要通过安全通道注入到容器文件系统或 secret 挂载中，且可以设置生成数量上限和生命周期。容器启动时使用这两个值向 Vault 登录，换取一个短期 token，再用该 token 读取具体的数据库凭据或静态密钥。
先准备一个 Vault 开发环境，docker-compose 配置如下：
version: "3.8"
services:
vault:
image: vault:1.13.1
cap_add:
- IPC_LOCK
environment:
VAULT_DEV_ROOT_TOKEN_ID: dev-only-root-token
VAULT_DEV_LISTEN_ADDRESS: 0.0.0.0:8200
ports:
- "8200:8200"
restart: unless-stopped
app:
build: ./app
environment:
VAULT_ADDR: http://vault:8200
ROLE_ID_FILE: /run/secrets/role_id
SECRET_ID_FILE: /run/secrets/secret_id
depends_on:
- vault
volumes:
- ./vault-agent:/vault-agent
在 Vault 中创建 AppRole 角色，并绑定一个只读策略，然后生成 role_id 和 secret_id。以下命令展示了完整的注册和登录流程：
# 创建名为 my-app-role 的 AppRole 并绑定策略
vault write auth/approle/role/my-app-role \
token_policies="my-app-policy" \
token_ttl=1h \
token_max_ttl=4h
# 读取 role-id
vault read -field=role_id auth/approle/role/my-app-role/role-id
# 生成 secret-id
vault write -f -field=secret_id auth/approle/role/my-app-role/secret-id
# 使用 role-id 和 secret-id 登录，获取短期 token
vault write auth/approle/login \
role_id=YOUR_ROLE_ID \
secret_id=YOUR_SECRET_ID
应用容器启动后，可以通过挂载的 secret 文件读取 role_id 和 secret_id，然后调用 Vault API 完成登录并获取数据库动态凭据。这种模式的优点是业务代码只需在启动阶段执行一次认证，后续数据库连接直接使用返回的用户名和密码，无需感知 Vault 的存在。缺点是需要自行处理 token 和凭据的续期，如果应用运行时间超过租约，必须重新登录或调用续期接口。
使用 Vault Agent 自动管理令牌和渲染配置文件
如果不想让业务应用集成任何 Vault 逻辑，可以使用 Vault Agent 作为 sidecar 容器运行。Vault Agent 负责自动认证、自动续期，并把最新密钥渲染到指定文件中。业务应用只需读取该文件，完全不用关心 Vault 地址、AppRole 凭据或租约管理。这种方式把 Vault 交互从业务代码中剥离，大幅降低改造和运维难度。
以下是一个 Vault Agent 的 HCL 配置示例，它使用 AppRole 登录，并把数据库连接信息渲染为应用可用的 JSON 文件：
pid_file = "/tmp/vault-agent-pid"
exit_after_auth = false
auto_auth {
method "approle" {
mount_path = "auth/approle"
config = {
role_id_file_path = "/vault/agent/role-id"
secret_id_file_path = "/vault/agent/secret-id"
}
}
sink "file" {
config = {
path = "/vault/agent/token"
}
}
}
template {
source = "/vault/templates/db-config.ctmpl"
destination = "/etc/app/config.json"
command = "systemctl reload app"
}
cache {
use_auto_auth_token = true
}
listener "tcp" {
address = "127.0.0.1:8200"
tls_disable = true
}
模板文件 db-config.ctmpl 中可以包含 Vault 模板语法，例如读取数据库动态凭据并输出 JSON。Vault Agent 在 token 续期成功后会自动重新渲染模板，并执行可选的 command 来通知应用热加载配置。这样即使数据库密码轮换，应用也能在无需重启的情况下更新连接信息。
在生产环境中，Vault Agent 通常以 sidecar 或 DaemonSet 形式运行，与业务容器共享同一个 Pod 或网络命名空间。需要注意的是，Agent 与业务容器之间的敏感信息传递最好通过共享卷文件而非环境变量，因为共享卷可以在应用读取后立即删除，降低泄露面。
生产环境中的租约续期、权限最小化与审计
动态凭据的租约续期是集成方案能否稳定运行的关键。数据库引擎生成的用户名和密码默认租约通常较短，比如 1 小时或更短。如果应用进程存活时间超过租约，连接池中的旧连接可能突然失效，导致服务中断。Vault 提供了 vault lease renew 接口，令牌可以续期，动态凭据也可以续期，前提是策略中允许 update 权限。如果使用 Vault Agent，自动续期由 Agent 处理，业务无需关心。如果手动实现，就需要在代码中捕获租约到期错误并重新获取凭据。
权限最小化是另一个必须坚持的原则。不要给应用 root token 或过于宽泛的策略。每个业务只应该能读取自己所需的密钥路径，并且只能执行必要的操作。以下策略示例只允许读取 database/creds/readonly 和 secret/data/myapp 下的数据，同时允许续期和吊销自己的 token：
path "database/creds/readonly" {
capabilities = ["read"]
}
path "secret/data/myapp/*" {
capabilities = ["read", "list"]
}
path "auth/token/renew-self" {
capabilities = ["update"]
}
path "auth/token/revoke-self" {
capabilities = ["update"]
}
审计功能对于追踪密钥使用情况至关重要。Vault 可以启用多个审计设备，把每次请求、响应状态和客户端信息记录到文件或 syslog。在出现密钥泄露或异常访问时，审计日志是定位问题的唯一依据。同时，建议定期轮换 AppRole 的 secret_id，并为 secret_id 设置 num_uses 或 ttl 限制，避免单个 secret_id 长期有效。
整体来看，Docker 与 Vault 的集成没有统一答案，需要根据团队规模、技术栈和部署平台选择合适的方式。对于轻量级场景，可以直接通过环境变量传入 role_id 和 secret_id，由应用完成 Vault 交互；对于规模化服务，Vault Agent 或 Kubernetes 的 Vault Sidecar Injector 更能降低运维压力。无论哪种方式，都要守住动态凭据、租约管理、最小权限和审计四条底线，才能真正利用 Vault 保护容器环境中的机密数据。