-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Implement watch #616
Comments
I've put info about current workarounds in |
The workaround of using a watch on the backing store makes sense, but it is possibly non-trivial to configure. For example, the Consul back-end keeps secrets in [vault mount]/logical/[some UUID]/. If there is only one mount of the Vault "generic" secret back end, then it is relatively easy to figure out which UUID is the root of my keys. However, if there are multiple "generic" secret back ends mounted, then it becomes difficult without resorting to other hacks. A possible solution would be to expose the "UUID" folder via an API call. Maybe this could be additional metadata on the call to /sys/mounts (e.g. /sys/mounts/[mount point]/detail)? Of course, native Vault watches would be nice as there is no guarantee that listening on the back-end will work correctly across upgrades. |
Another workaround is to create a secret in the mount whose name identifies the mount: |
We eventually want to have an eventing system but it's a ways out on our roadmap. I'm closing this however since it is on our roadmap! |
Kubernetes allows you to watch for changes to a resource. There's been some discussion about using vault with Kubernetes and Vault's lack of watch support was raised as something that might make this difficult. I imagine that the consul, etcd, and zookeeper stoage backends should all support this.
The text was updated successfully, but these errors were encountered: