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

KV backend secret path operation events #8569

Open
Zenithar opened this issue Mar 16, 2020 · 3 comments
Open

KV backend secret path operation events #8569

Zenithar opened this issue Mar 16, 2020 · 3 comments
Labels
core Issues and Pull-Requests specific to Vault Core enhancement

Comments

@Zenithar
Copy link

Zenithar commented Mar 16, 2020

Context

We build a secret path naming specification in order to organise all secrets inside the secret management process and secret storage.

Problem

I studied Vault, and for the moment it will require us to fork, to add a custom plugin for KVv2 backend that adds the control on secret path creation. This process is not straightforward due to the fact that it will require us to follow Vault evolution to merge all updates.
I don't want to lose the ability to use directly Vault so that I don't really want to add tool before Vault to enforce the secret path when they are stored in Vault.

Is it possible to enforce a secret path naming convention, using a dedicated webhook? so that the remote component/plugin will be able to receive the secret path and decide if the path is compliant with our specification?

Request

It would be great to be able to register event handlers (Webhook, etc.) on the backend (CREATE / DELETE / etc.) so that we could filter/trigger operations.

@tyrannosaurus-becks
Copy link
Contributor

tyrannosaurus-becks commented Mar 16, 2020

Hi! It may presently be possible to enforce naming conventions using Sentinel, which is an enterprise feature. Here are some resources regarding Sentinel for you to look at:

Does that look like it may solve your use case?

@tyrannosaurus-becks tyrannosaurus-becks added waiting-for-response core Issues and Pull-Requests specific to Vault Core labels Mar 16, 2020
@Zenithar
Copy link
Author

Ok, but I made an HTTP microservice that implements the complete naming specification and controls, I don't want to maintain 2 different implementations one for Sentinel, and one for my microservice.

Also, I don't have Vault Enterprise, so for the moment, I'm stuck to wrap Vault call to enforce secret path naming before accessing Vault.

@aphorise
Copy link
Contributor

aphorise commented Sep 3, 2022

This is a reasonable request and I feel it should get some ❤️

To advocate for it further - I'd contest why cant an arbitrary hook / trigger be provided for any Secrets or Authentication event?

Simply put - for any given secret change or login (eg login, or creation / update of doc) there could be a generic, non-guaranteed, web-hook which the user can enable / set at their own risk and wish would trigger when particular documents are written or updated for example or a special user logins for whom further triggers may be required.

I can also see this playing into other flows like new / first account creation or other event driven activity related to the users identity, access and the secrets they are creating in particular spaces.

@briankassouf @ncabatoff @mladlow @calvn - if anyone you folks have any opinion on this then I'd love to hear more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Issues and Pull-Requests specific to Vault Core enhancement
Projects
None yet
Development

No branches or pull requests

3 participants