hashicorp / vault

A tool for secrets management, encryption as a service, and privileged access management
https://www.vaultproject.io/
Other
31.07k stars 4.2k forks source link

KV backend secret path operation events #8569

Open Zenithar opened 4 years ago

Zenithar commented 4 years ago

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 commented 4 years ago

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?

Zenithar commented 4 years ago

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 commented 2 years ago

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.