More secret drivers!

[trusch]

I want to raise the idea of supporting more backends for the secret subsystem. Currently only the default clear-text file based driver and the pass driver are available. We currently have a use case where we would like to use the cloud native secret management systems from Google and amazon. Since I know it's not really hard to write a secret driver (I wrote the pass driver), I'd like to know how the maintainers think about eventually accepting a PR that adds support for those secret backends.

Thanks for the feedback in advance!

[Luap99]

How would code for such drivers look like? Do you envision to shell out to external commands or want to do this directly in the go code? I think the former would be better as the later will be much more maintenance work that I would not like. So if the goal is just convenient access to cloud secrets then I would not object as long as the code is easy enough to maintain.

However I am not sure how much value these drivers add. Currently there are no encrypted secrets really. I mean sure the driver itself might store it securely but as soon as a container is created the secretes are extracted in plain text into the container storage dir (not on tmpfs) and are only removed when the container is removed.

[MrMarble]

How would code for such drivers look like? Do you envision to shell out to external commands or want to do this directly in the go code?

I think it could be done similar to how docker does it, they have a sdk to help write plugins, basically you implement a Go Interface and use the sdk Handler to create a a slim container internally managed by docker engine that exposes a socket to communicate with the engine.
I wrote a very simple secrets plugin for docker to connect to 1Password connect server, here's the code as an easy to read example https://github.com/MrMarble/opsd.

Another option could be to use Hashicorp's plugin system

I mean sure the driver itself might store it securely but as soon as a container is created the secretes are extracted in plain text into the container storage dir (not on tmpfs) and are only removed when the container is removed.

Isn't that the same way Kubernetes secrets work? Once you use the secrets as environment variables or mount it as a file it can be read from any process inside the container.

At work we use bitwarden cli and HashiCorp vault with some custom bash scripts to inject the secrets in the containers, having custom drivers could simplify development by a lot

[rhatdan]

One difference between a k8s environment and a podman/docker environment is the containers are killed by default in k8s. In the Podman world the container remains untile the user removes it unless the container was run with the --rm flag. This means the container might expose the secret on disk while the container is not running.

Bottom line we would consider at a PR containing a plugin secret,

[bexelbie]

I've been trying to solve a problem that involved using a 1Password Service Account as the source of secrets. I found #25118 where @ivanfed0t0v posted a PoC using the shell driver to use systemd-creds. What I discovered in adapting his idea was that podman secrets insists on having all secrets pre-created and then only passes its internal id, not any externally available id, in for future lookups.

I feel like your solution would be a template for solving this issue, so I support it. This is a bit old, so I hope the encouragement helps.

As an aside, we seem to be lacking any serious documentation or examples of either the shell or pass drivers. Are they actually consumed and tested?