Suggestions for docker, sonarqube, and secret keys


Apologies if this is not the correct forum for these types of questions, however, I was wondering what would be a good approach for handling sonar-secret files with docker?

What I am trying to achieve, is to create a docker image, where its contents can be stored in source control (not just the image, but the contents used to create the image as well). While using a sonar-secret file as described in the Setting Encryption section.

The issue starts with the secret key being visible in the sonar-secret.txt file, which we don’t want (when stored in our repo). I’ve looked into (but have yet to test) docker secrets, but it looks as if they only work with swarm (which we aren’t using)?

We could try using environment variables, or mounting the sonar-secret.txt file, however, not sure if these are “best practices”. I’m new to both docker and sonarqube, so apologies if I’m asking basic questions. Any help would be greatly appreciated, thank you.

Sonarqube version: v6.7.5


1 Like

Hi Erik,

I think this is not specifically tied to SonarQube, but can relate to many projects and setups. In any case, I think you will have to mount the secret key at runtime, which is likely the more secure approach. At build time would defeat the purpose entirely (but I’m sure you got that already), and via environment variables is not really supported in SonarQube for this particular case (yet).

I’m not sure what the general agreed-upon best practice is within the Docker community, but from my experience, here’s some things I would explore and discuss with the team, to see what fits your organization:

Storing the encryption key in the repo
Although you do not want to store such data in clear text, there are ways for sensitive data to be stored in repositories, encrypted. Git itself has utilities to encrypt/decrypt files, which basically allow you to store the file encrypted in the repo, but decrypt it locally when checking out. This is done via .gitattributes, and even though I haven’t used it personally, I know companies that use it to store all sensitive data related to a project, directly in Git.

The big advantage of this, is that the mount location can be “hard-coded”. This is especially useful if you use something like Docker Compose, or have custom shell scripts to simplify the running of your image.

Check out git-secret and git-crypt.

In your particular case, I think this would be my personal preference.

Not storing the encryption key in the repo
If organization guidelines don’t allow you to store sensitive information, even encrypted, along with your project code, you will need to find a way to share an encrypted version between colleagues.

There are multiple ways to achieve this, like putting an encrypted file on a shared drive, passing a USB stick, etc. But I’d go for something a bit more advanced. At a previous company I worked for, we would share sensitive information (including SSH and encryption keys) using pass, tied to a central Git repo (if on Windows, KeepassX is similar, but not as good IMHO). This allowed us to keep all keys up-to-date, and because it uses GPG under the hood, you can use large key sizes to make the encryption very strong. And because you usually register each machine (desktop, laptop, server) that has access to this store independently (like you would with SSH keys), it’s pretty secure and robust. I know my example here also uses Git, but you could have it run on a different server, perhaps only within the local network (we did this on a Raspberry Pi in the office).

The downsides of this are:

  • Extra overhead for the sharing of this secret key file. How do you keep this secure, while also allowing the team to be efficient?
  • You need to define a set of rules within the team. How do you mount this file? Where do you store it on your own machine? How do you update it if necessary?

Anyway, sorry for the long reply :sweat_smile:. I hope this gives you some food for thought. And if you approach the Docker community for some best practices on their side, I’d be interested to hear about it :slightly_smiling_face:.


Thank you @Wouter_Admiraal for your response. I will take this information to my team and move from there. As this question is “open-ended”, I will just close it for now and mark your answer as the solution (since yous is the only answer :slight_smile: )

Thanks again.

Edit: Well, not sure how you close it. But marked @Wouter_Admiraal’s answer as the solution :slight_smile: