如何将Docker Secrets注入application.properties文件 使用环境变量是否安全

实现/run/secrets下Docker Secrets注入的常用方法 #

• 入口脚本动态生成配置（全版本通用，无需修改应用代码）
  编写容器启动入口脚本，在应用启动前读取/run/secrets下的密钥文件，替换application.properties中的占位符，示例脚本如下：

  # 读取密钥内容
  DB_PASSWORD=$(cat /run/secrets/db_password)
  REDIS_PASSWORD=$(cat /run/secrets/redis_password)
  # 替换配置文件中的占位符（示例中占位符为@DB_PASS@、@REDIS_PASS@）
  sed -i "s/@DB_PASS@/$DB_PASSWORD/g" /opt/app/application.properties
  sed -i "s/@REDIS_PASS@/$REDIS_PASSWORD/g" /opt/app/application.properties
  # 启动应用
  exec java -jar /opt/app/your-app.jar
  

  最后在Dockerfile中将该脚本设置为ENTRYPOINT即可。

• Spring Boot原生导入（适用于Spring Boot 2.4+版本）
  Spring Boot原生支持从文件导入配置，直接在application.properties中添加以下配置即可自动读取对应密钥：

  # 导入/run/secrets下的所有密钥，密钥文件名需和配置项名完全一致
  spring.config.import=optional:file:/run/secrets/
  

  如果不想用全配置名作为密钥文件名，也可以单独指定映射：

  spring.datasource.password=${file:/run/secrets/db_pass}
  

• 环境变量中转实现
  启动容器时将密钥内容读取到环境变量，利用Spring Boot自动映射环境变量为配置项的特性完成注入，启动命令示例：

  docker run -e SPRING_DATASOURCE_PASSWORD=$(cat /run/secrets/db_password) your-image-name
  

环境变量实现方案的安全性分析 #

不推荐使用环境变量传递敏感信息，安全性远低于直接读取/run/secrets下的密钥文件，原因如下：

• 环境变量容易意外泄露：执行docker inspect可以直接查看容器所有环境变量的值，很多应用、监控组件默认会采集打印进程环境变量，很容易导致敏感信息外泄。
• 破坏了Docker Secrets的安全隔离设计：Docker Secrets默认存储在tmpfs内存文件系统中，只有容器内指定用户有权限读取，导出到环境变量后，任何有权限访问应用进程的用户都可以获取到敏感值。
• 配置文件泄露风险：如果在docker-compose、K8s编排文件中直接配置环境变量和密钥的映射，不小心提交到代码仓库会直接导致敏感信息泄露。

特殊场景必须使用环境变量的话，建议仅在入口脚本中临时导出环境变量，应用启动后立即销毁变量，不要在容器层面全局设置环境变量，可降低泄露风险，但安全性仍然远低于直接读取密钥文件。

内容的提问来源于stack exchange，提问作者BlueAtlas