Could this be used with a docker volume plugin?

[hekaldama]

I am currently evaluating summon to be a solution for secrets inside docker. I see there is an example of injecting it into the ENV by wrapping the docker command with a summon command and I am currently running this to see how it behaves.

I don't think this will work with my longer term goal which is to interact with docker through docker APIs &&|| cli thereby bypassing the summon wrapper type interface.

Essentially I need to be able to do something like:

docker run -v secrets:/secrets:ro --volume-driver summon alpine

and either have /secrets be a file of newline separated K:V pairs, a directory tree of /secrets/:key where the contents of the files are the corresponding values, somehow have it be a memory mapped file, or somehow be able to inject it via the --env-file flag.

I am currently prototyping some things, but I am curious to get the communities thoughts on this as well.

Thanks in advance!

[dustinmm80]

Hey @hekaldama thanks so much for bringing this up!

This feature has been on my mind for a while, just haven't had time to come up with a prototype. Do you have something you could share in a PR, perhaps?

Basically we all know passing secrets as env vars to containers is a bad idea, today. Summon was written when Docker when still ramping up, so I just used env vars because other tools we use work great that way. I would like this to be done in a standards-appropriate way. I don't see an official standard from the OCI, but /run/secrets as a folder seems popular. We already have some temp file logic in summon core (that's what makes !var:file work).

So yeah, as you said - /run/secrets/<key>/<value> seems pretty perfect. PRs welcome :)

[dustinmm80]

Similar conversation going on here: https://github.com/conjurinc/summon/issues/42

[dividedmind]

I've read through the docker volume API and it's not clear to me there's a (straightforward) way to provide the required security properties and separation with this approach. Definitely some docker-specific (or -friendly) way would be a very useful feature, but some further research would be needed as to what'd be the best way to accomplish that.

@hekaldama, could you describe the issues you're seeing with the environment variable approach in more detail? I'm not sure if I understand fully, maybe there's a simple hint to make it work better for your scenario.

[hekaldama]

Hey all! Thanks for the comments. I have moved on to entirely different problems that doesn't currently involve docker and would be more than happy to weigh in on this, but I don't have much to say at this moment. Feel free to close this out if desired.

[ryanprior]

Closing this issue as Docker now has explicit support for secrets providers, which is always what we wanted for this use case: https://blog.docker.com/2017/02/docker-secrets-management/