Secrets managers support for mirth.properties

[kpalang]

Morning!

An question came up in Mirth connect Slack channel about storing and accessing secrets in containers.
So one has to store for example, database credentials, in mirth.properties file, which by default is plaintext. According to Mirth Wiki page it is possible to encrypt the properties file after the first run, but that still leaves the credentials in the open in a couple of places.

I think it would be a good idea to have support for external credentials managers, like Docker Swarm/Compose secrets, K8s secrets, Azure identity tools, HashiCorp Vault etc.

And a cherry on top would be a pluggable architecture, so community can write additional adapters.

[pacmano1]

The devil is in the "etc." part though, what managers to support. That should probably be a market share weighted choice - perhaps only NG can extrapolate where folks are running engines although I don't know how much telemetry data is actually collected in their systems. I know folks will kill me on this - it should also be weighted by paying customers as a priority also. And should it be free? I am of course assuming that credential manager integration points are different enough to warrant some ordering in development.

[kpalang]

Well I as an avid open source person would love for this to be open too. Then again, those adapters would be a good place for NG to cash in. As to which managers to support, I'd start with Docker secrets. But I suppose having a customer weighted poll is not a bad idea either.

[tonygermano]

The mirth.properties file can be configured with an environment variable reference instead of a hard coded value, so as long as you have a way to get the secret into an environment variable prior to mirth startup, you shouldn't have to touch the mirth.properties file or worry about encrypting any files in the container

[tonygermano]

https://commons.apache.org/proper/commons-configuration/userguide/howto_basicfeatures.html

Specifically in the Variable Interpolation section

java.home = ${env:JAVA_HOME}

[kpalang]

Ooh that's handy.

[kpalang]

But doesn't this leave secrets in plaintext in env?

[psapozh]

In the case of kubernetes this leaves a password visible in the kubernetes deployment definition yaml. So ideally password that I would set in env variable would have to be already hashed at a time that it gets set there. Then un-hashed once mirth reads it.

[tonygermano]

@kpalang yes, it would be in plaintext in env, but not in the filesystem

@psapozh I don't use kubernetes, but can't you use secrets for this? https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-environment-variables