search

hashicorp / vault

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

Create a k/v secret that is a symlink of another one #9781

Open agaudreault opened 4 years ago

agaudreault commented 4 years ago

Is your feature request related to a problem? Please describe.

In vault (with the k/v secret engine), we have strict ACL policies on which group can read or create secrets. Most of the time, we only want one group that can edit a secret (the owners) and we have multiple groups on read (the audience). One problem that happens is when an audience need to share that secret to another group or a service user.

For instance, let's say there is a api token secret foo at /secret/team-1/team-2/foo where team-1 have RW and team-2 have RO. The API token is created by the team-owner and shared this way with the team-read.

Now team-2 wants to use the value of that secret for the actual service service-1.

Right now we have 2 options that are far from ideal.

  1. Copy the secret to /secret/team-2/service-1/foo where team-2 has RW and service-1 have RO.
    • This cause duplication.
  2. Update the ACL to allow service-1 to READ on /secret/team-1/team-2/foo.
    • This would cause the ACL to be updated very often and will get out of control extremely fast.

Describe the solution you'd like

A secret that would be a symlink of another one. You could create it if you have write access on the new path and read access on the symlink reference.

When the underlying secret is deleted, symlink would still exist, but the result would be a 404 since it does not have data.

Describe alternatives you've considered

We could also use another path convention such as /secret/service-1/team-1/team-2/foo with team-1 as RW and the others as RO, but with that pattern, it becomes quite hard for team-1 to know all the secrets they own.

Additional context This is really just brainstorming the idea as I assume this has a lot of technical difficulties, but any solution that would prevent a secret to be copy/pasted in different path would be ideal :)

jamesblackburn commented 3 years ago

Looks like this is a popular request #1284

abarclay commented 1 year ago

Is this enhancement getting any traction? If not, I think I'm just going to implement a task that copies secrets from one path to another in vault. If it got executed once per hour then things would be eventually consistent.

ArieLevs commented 1 month ago

A highly significant feature request, which was originally submitted 8(!) years ago (https://github.com/hashicorp/vault/issues/1284), highlights the lack of a unified source of truth for secrets for teams/applications. 😞

Are there any plans to implement this feature in the (near) future?