docker-compose中环境变量如何安全传递？

Question

在使用 Docker Compose 部署应用时，如何安全地传递敏感环境变量（如数据库密码、API 密钥）是一个常见难题。直接在 `docker-compose.yml` 中明文定义环境变量（如 `MYSQL_ROOT_PASSWORD: mysecretpassword`）存在严重安全风险，可能导致凭据泄露至版本控制系统或被未授权人员访问。常见的疑问是：应如何结合 `.env` 文件、环境变量引用与外部密钥管理工具（如 Hashicorp Vault 或 AWS Secrets Manager），在保证开发便捷性的同时实现生产环境的安全隔离？此外，`env_file` 与 `environment` 的权限控制和加密处理机制也常引发困惑。

Answer 1

一、Docker Compose 中安全传递敏感环境变量的深度解析

1. 问题背景与常见误区

在使用 Docker Compose 部署应用时，开发者常将数据库密码、API 密钥等敏感信息直接写入 docker-compose.yml 文件中，例如：

environment:
  MYSQL_ROOT_PASSWORD: mysecretpassword

这种做法存在严重安全隐患。一旦该文件被提交至 Git 等版本控制系统，敏感凭据将永久暴露，即便后续删除也难以彻底清除历史记录。

常见的误区包括：

• 认为 .env 文件本身是安全的（实际仍需权限控制）
• 混淆 environment 与 env_file 的作用域和安全性差异
• 忽视生产环境中动态密钥获取机制的重要性

2. 基础防护：利用 .env 文件实现配置隔离

Docker Compose 支持从 .env 文件加载变量，实现明文解耦：

# .env
MYSQL_ROOT_PASSWORD=prod_secret_123
API_KEY=sk_live_xxxxxxx

在 docker-compose.yml 中引用：

environment:
  MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}

并通过 .gitignore 排除 .env 提交：

.env
*.env.local

此方法适用于开发与测试环境，但未解决静态存储风险。

3. 权限控制与文件管理策略

为增强安全性，应对敏感文件实施操作系统级权限控制：

文件类型	推荐权限	说明
.env	600 (rw-------)	仅属主可读写
docker-compose.yml	644 (rw-r--r--)	常规配置文件权限
scripts/load_secrets.sh	700 (rwx------)	脚本执行权限限制

可通过命令设置：chmod 600 .env

4. env_file 与 environment 的对比分析

两者均可传递环境变量，但在安全模型上有显著区别：

• environment：直接定义或引用变量，适合少量关键参数
• env_file：从外部文件加载多个变量，便于集中管理

示例：

env_file:
  - ./config/secrets.env

注意：env_file 不支持变量插值，且所有内容均会注入容器，需谨慎筛选内容。

5. 进阶方案：集成外部密钥管理服务

在生产环境中，应结合 Hashicorp Vault 或 AWS Secrets Manager 动态获取凭据。

以 AWS Secrets Manager 为例，启动前通过 CLI 获取：

aws secretsmanager get-secret-value --secret-id db/password --query SecretString --output text

可在启动脚本中动态生成临时 .env.tmp 文件：

#!/bin/bash
SECRET=$(aws secretsmanager get-secret-value --secret-id app/api_key --query SecretString --output text)
echo "API_KEY=$SECRET" > .env.tmp
docker-compose --env-file .env.tmp up

6. 使用 Hashicorp Vault 实现统一密钥治理

Vault 提供加密存储、访问策略、审计日志等企业级能力。

流程如下：

graph TD A[应用启动] --> B[Docker 容器请求令牌] B --> C[Vault 验证身份] C --> D{是否授权?} D -- 是 --> E[返回解密后的密钥] D -- 否 --> F[拒绝访问并记录日志] E --> G[注入环境变量]

通过 Vault Agent Injector 可自动完成注入过程，无需修改应用代码。

7. 多环境安全隔离架构设计

建议采用分层配置结构：

config/
├── dev.env
├── staging.env
└── prod.env.enc   # 加密文件

使用 ansible-vault 或 sops 对生产环境文件加密：

sops --encrypt prod.env > prod.env.enc
sops --decrypt prod.env.enc > .env

结合 CI/CD 流水线，在部署时自动解密并加载。

8. 最佳实践总结与技术选型建议

根据团队规模与系统复杂度选择合适方案：

• 小型项目：.env + gitignore + chmod 600
• 中型系统：sops 加密 + GitHub Actions 解密
• 大型企业：Vault 集成 + Kubernetes CSI Driver

始终遵循最小权限原则，避免将全部密钥暴露给所有服务。