敏感变量严禁硬编码进Dockerfile，应通过--secret、--env-file（配合.gitignore与环境隔离）、Docker Secrets或K8s Secret等机制分层管控，并在运行时限制inspect/exec、过滤日志、禁用env命令以防泄露。
直接用环境变量传密钥、在 dockerfile 里写密码、把 .env 提交进 git——这些操作看似省事，实则一步踩进高危区。安全加固的关键不是“多加一层”，而是从变量来源、注入路径、运行时暴露三个环节切断泄露链。
敏感变量绝不能硬编码进镜像
ENV 指令写在 Dockerfile 里，哪怕后面 RUN rm -f config.json，密钥仍会固化在某一层中，docker history 可轻松提取。这不是“删了就没了”，而是“删了还在”。
- 禁止在 Dockerfile 中使用 ENV 设置 API_KEY、DB_PASSWORD 等敏感值
- 非敏感通用配置（如 APP_ENV=prod）可保留，但需与敏感项严格分离
- 构建阶段若需临时凭证（如拉私有模型），应使用 Docker BuildKit 的 --secret 机制，而非环境变量
优先用 --env-file，但必须配合隔离措施
.env 文件本身不加密，它的价值在于“脱离代码、集中管理”。但仅靠它远远不够，必须叠加访问控制与生命周期管理。
- 所有 .env 文件必须加入 .gitignore，CI/CD 流水线中禁止上传或缓存
- 开发用 .env.local，生产用 .env.prod，文件名明确区分环境，避免误加载
- 启动容器时显式指定：docker compose --env-file .env.prod up，不依赖默认 .env 自动加载
- 在入口脚本（如 entrypoint.sh）中校验关键变量是否存在，缺失则 exit 1 并输出清晰提示
生产环境必须启用 Docker Secrets 或外部密管
单机开发可用 --env-file，但集群化、多副本、滚动更新的生产场景，必须升级密钥分发机制。
- Docker Swarm 模式下，用 docker secret create 注入密钥，服务通过 /run/secrets/ 目录挂载读取，不落地、不透出
- Kubernetes 环境统一使用 Secret 资源，配合 RBAC 控制读取权限
- 云原生场景推荐接入 AWS Secrets Manager、Azure Key Vault 或 HashiCorp Vault，实现动态获取+自动轮换
- 应用内不要缓存密钥到内存变量中超过必要时间，尤其避免日志打印 process.env.SECRET_KEY
运行时环境也要防“看得见”的泄露
即使变量来源安全，容器运行后仍可能被窥探。攻击者只需 docker inspect 容器ID 或 exec 进去 echo $VAR，就能看到明文值。
- 禁用不必要的 docker exec 权限，限制只有运维人员可进入生产容器
- 在容器内禁用 env 命令（可通过 seccomp 策略拦截）、限制 /proc/environ 可读性
- 应用日志框架需全局过滤敏感字段名（如 *key、*token、*password），防止意外输出
- 对 PHP、Node.js 等语言，避免在错误堆栈中暴露环境变量（例如未捕获异常打印 process.env）
