Require the ability to store certs/keystores in the secret store

[Mark-J-Lawrence]

Background

We want to use the Docker Manager in our tests. We have a Ubuntu server with a docker engine configured, and following their strong recommendations, we want to protect the daemon socket to stop just anyone from running containers on it.

There seems to be only two viable ways to protect it, SSH or HTTPS via TLS. HTTPS seems the most sensible option, which requires creating a bunch of certs (and likely importing into a keystore) and providing the connection with them.

Currently, the Docker manager does not support any form of authentication protection when connecting to a docker engine, though I'm in the process of developing it to do so. It uses the HTTP manager to communicate with the docker engine, it therefore seems that it would need to make use of setupClientAuth() to provide a keystore with the certs to connect to docker within them.

The issue is, how is this keystore created or obtained by the docker manager? I've not spotted anything that might help so far....

Secrets can currently only store user, pass, token. I could try passing all the certs as tokens, and then build the keystore in the Docker Manager code, though its not a very professional solution.

The correct solution would be the ability to tag a docker engine with a "secrets" tag in the CPS, the docker engine then consults the store to obtain the secret with that tag, and the keystore is returned which can then be passed into setupClientAuth(). This would however mean extending the secret store to accept binary files.
An alternative is to store the 3x certs used to build the keystore into the secrets store, and the Docker Manager creates the keystore on-the-fly.
Another alternative, is we can clone the docker manager internally and bake a jks into the code, which obvious doesn't help anyone else.

Or perhaps something already exists?

Tasks

• <task>