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 
. 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 
.
)