Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Docker secrets plugin #4273

Open
kinghuang opened this issue Apr 4, 2018 · 12 comments
Open

Feature Request: Docker secrets plugin #4273

kinghuang opened this issue Apr 4, 2018 · 12 comments
Labels
community-sentiment Tracking high-profile issues from the community ecosystem enhancement feature-request
Milestone

Comments

@kinghuang
Copy link

Feature Request:

Docker 17.10 added support for pluggable secrets backends (docker/cli#366). It would be useful if there was a Docker secrets plugin for Vault.

Expected Behavior:

A Docker secrets plugin that can be installed and used when creating secrets for use with Docker containers and services.

Actual Behavior:

There is no plugin available that I'm aware of.

Important Factoids:

N/A

References:

The template for Docker secrets plugins is available at docker/go-plugins-helpers/secrets.

@jefferai
Copy link
Member

jefferai commented Apr 4, 2018

I took a look at the interface. I'm not sure this is something that can be satisfied; the interface is not very rich. I suppose if this only ever used the K/V store it might work, although I didn't see any information about how one would secure the Vault token used to get access (search for 'auth' in https://docs.google.com/document/d/1kNA6apIFAiaE9d96A2_rcEulVrglvq05zEXGdijSZac/edit -- it doesn't exist), or use different tokens across different containers without having them all have access to all secrets, not to mention the API is different between a versioned and non-versioned K/V store.

Also, their design doc states that it's for read only fetching of secrets, not creating secrets.

I don't at the moment see how this is possible.

@jefferai jefferai added this to the not-scheduled milestone Apr 4, 2018
@kinghuang
Copy link
Author

Ah, I didn't notice that design doc in there. I'm actually most interested in reading secrets directly from Vault. It'd cut out a middle step of reading secrets from Vault and creating corresponding Docker secrets in order to pass them on to services. But, I agree, based on that design doc the interface is a bit lacking right now.

@mariotacke
Copy link

Has anything changed in the interim? I'm in the same boat now: i'd like to use docker secrets with vault.

@hongkongkiwi
Copy link

Me too, this is pretty essential to using Vault in production.

@hongkongkiwi
Copy link

hongkongkiwi commented Nov 16, 2019

Thank you, the idea is solid, I'm just stuck on the proof of concept part. It would be great to have something a bit more solid and supported to implement in production.

The other option that we are exploring is envconsul. This allows you to replace the entrypoint with this and then run the original entry point. This will inject the variables as env vars. It's cool, but is missing the feature of saving the secrets as a file.

There's another option which does also does the env trick called: vaultenv

I hope the Vault team can officially add support for this. To me it's a huge use case for Vault.

@sirlatrom
Copy link

@hongkongkiwi Indeed, since it's something I implemented and will augment for in-house use, it is not a supported solution. We'd also much prefer an official plugin from HashiCorp.

Envconsul works fine depending on your secret structure. If you have a general pattern (i.e. global, environment specific and service specific layers with a well defined order of precedence), you'll have to make sure any KV paths you'll refer to actually exist in Vault, as a missing secret will make envconsul error out. That behaviour is different compared to when used with Consul, as missing keys are simply ignored in that case.

Either way, you still have to deliver the Vault token to envconsul, and so you have to either accept long lived tokens shared between all tasks of a service, or use s plugin like mine ;)

@sebastianzillessen
Copy link

Any updates on this?
We would like to introduce vault to our production environment, currently using docker swarm and local deployments (secrets are stored on the swarm manager in the file system).

Our setup:

  • We would like to introduce remote deployments from a CD (Jenkins)
  • The CD should never have access to the secrets stored in Vault.
  • The Developer deploying from the CD should not have access (direct or indirect) to the Secrets, so he/she is not allowed to view any tokens.
  • right now we have static secrets.
  • We are using docker swarm right now.

Any ideas how we could proceed?

Thanks!

@sandstrom
Copy link

There seems to be a Docker Go Plugin API for this:
https://github.com/docker/go-plugins-helpers/tree/master/secrets

@sirlatrom
Copy link

There seems to be a Docker Go Plugin API for this:
https://github.com/docker/go-plugins-helpers/tree/master/secrets

@sandstrom That's the exact SDK I used in the plugin I've mentioned a couple of times: #4273 (comment)

Anyone who wants to are free to fork it and improve it if they feel like it.

@pbernal pbernal modified the milestones: not-scheduled, triaged May 28, 2020
@heatherezell heatherezell added the community-sentiment Tracking high-profile issues from the community label Jan 18, 2022
@PaarthShah
Copy link

Any update on this?

@e-scheer
Copy link

e-scheer commented Oct 3, 2024

I was just catching up on this thread and wondering if there have been any updates or movement regarding the Docker secrets plugin for Vault? It looks like there’s a lot of interest in having a more robust, supported solution for production environments around docker (and swarm). The POC and plugins shared here (like sirlatrom’s plugin) are interesting, but something official from HashiCorp would definitely go a long way in addressing many of the challenges mentioned—especially around token security and dynamic secrets management in Docker Swarm or Kubernetes environments.

Any news or feedback from the Vault team on whether this is being considered for development?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
community-sentiment Tracking high-profile issues from the community ecosystem enhancement feature-request
Projects
None yet
Development

No branches or pull requests