Replies: 1 comment
-
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. |
Beta Was this translation helpful? Give feedback.
-
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!
Beta Was this translation helpful? Give feedback.
All reactions