Consider adding SONAR_JDBC_PASSWORD_FILE environment variable for Docker

SonarQube Server / Community Build
, ,
1

Must-share information (formatted with Markdown):

  • which versions are you using: 26.7.0.124771-community
  • how is SonarQube deployed: Docker
  • what are you trying to achieve: be able to deploy with the JDBC password secured in a Docker Swarm secret
  • what have you tried so far to achieve this: deploy with the full sonar.properties file saved as a Docker secret, rather than just provide the JDBC password this way

It would be great if SonarQube supported an alternate way to provide the JDBC password, via an environment variable SONAR_JDBC_PASSWORD_FILE which contained a path to a file that holds the JDBC password. Docker Secrets will only bind-mount secrets into containers as files (in a read-only, RAM-disk-backed mount), so many Dockerized apps have added the option to append _FILE to many/all environment variables intended to hold secrets, and then read the contents of the file to provide the secret to the app. For example, see Postgres — running a Docker stack of SonarQube and Postgres allows me to put the Postgres DB password into a Docker secret and pass it to the Postgres service with a file-based environment variable, but not to SonarQube the same way.

Note that for now, the way I’m getting around this is by fully replicating the entire sonar.properties file, adding the password there, storing the entire file as a Docker secret, surfacing that secret to the SonarQube service (at /run/secrets/sonar.properties), and then bind-mounting that file to the container at /opt/sonarqube/conf/sonar.properties. But this then means that I have to take responsibility for the entire contents of the file forevermore; if and when SonarQube adds new options, changes defaults for options, etc., I’m responsible for tracking those changes. It’d be great to be able to just provide the password alone in a new environment variable intended to hold a file path in which the password is written, and have the container pick that up appropriately.

2

Hey @delfuego, thanks for describing your use case, you are right that this is not currently supported. We are aware of this gap, in fact we have an item in our public roadmap portal. You can vote for it to help prioritize it. There’s also a Jira ticket about it.