Feature Request: Secret References (Secrets that reference other secrets)

MarkRx commented 1 year ago

TLDR - It would be useful to have secrets that are a "pointer" / "link" to another secret similar to how file links work on a filesystem.

Overview

There are many ways to organize secrets in vault. Two such ways are organizing by consumer (reader) and producer (owner).

When organizing by consumer Vault may be structured like the example in the Recommended Pattern for Vault ACL Policy Path Templates documentation:

secret/<namespace>/<application>[/<secret>]

In this model every application has its own secret or set of secrets. It makes access straight forward at the cost of maintenance when values change. Should many applications share the same secret then when a credential is rotated it must be updated in all of the secrets of applications that use it.

When organizing by owner Vault may be structured like something below:

secret/<line_of_business>/<team>/[.../]<secret>

In this model a credential only exists once within a folder structure that relates to the owner of the secret. Updating the secret becomes straight forward as there is a single source of record for the value. This comes at the cost of complexity when consuming the secret - each application must maintain a catalog of secrets it needs to pull.

Possible Solution : Secret References

It's possible to get the best-of-both-worlds of the two approaches above by supporting secret "views". The view would represent a read-only view on a collection of secrets that can be read at an alias path. Applications would point to a "view" in Vault.

Consider an example:

secret/it-dba/oracle-team/myorg-microservice-database-creds

Contains keys for username and password owned and maintained by the oracle DBA team to connect to a shared database

secret/it-enterprise/user-management/userservice-creds

Contains keys for username and password owned and maintained by the Enterprise Services user management team

Secret Ref: secret/cool-app-suite/microservice1/database-creds -> secret/it-dba/oracle-team/myorg-microservice-database-creds

Refers to the contents of secret/it-dba/oracle-team/myorg-microservice-database-creds

Secret Ref: secret/cool-app-suite/microservice2/database-creds -> secret/it-dba/oracle-team/myorg-microservice-database-creds

Refers to the contents of secret/it-dba/oracle-team/myorg-microservice-database-creds

Secret Ref: secret/cool-app-suite/microservice3/rest-creds -> secret/it-enterprise/user-management/userservice-creds

Refers to the contents of secret/it-enterprise/user-management/userservice-creds

In this example the password for the microservice-database only exists in one location. Updating the value thus becomes straight forward. Additionally, since applications use references to other secrets it's easy for a consumer to access anything it needs within the context of a folder optimized for reads.

Access control would occur in two places. First the reference must be granted access to read the secret it is referencing. Second, the alias path to the reference must have a policy setup for consumers to use it. Any such policy will always be a subset of the permissions granted to the targeted value.

Workaround

It's possible to make up for the cases above through external systems in vault. In the case of secrets organized by consumer a credential rotation system must keep a catalog of all locations in vault where a secret must be updated. In the case of secrets organized by owner each application must keep a catalog of all secret paths it needs and pull them.

These workarounds could be avoided if vault supported secret references

MarkRx commented 1 year ago

Looks similar to #9781 and #1284

notjames commented 1 year ago

Another use-case to bolster the ask for symlink-like or secret references is something we're running into in our environment. Because of how our environment is set up, we don't use vault's native secret rotation. We've built our own. We've also got a zero down time (ZDT) model that we use for rotating credentials which requires two sets of secrets (active/passive) let's say. Applications automatically reference a set of credentials from vault. Ideally, it would be great if the creds which they reference never change, however the rotated secrets, which do obviously change, would be the only secrets to which the application credentials point. For example:

/path/to/application/username
                    /password  -> /path/to/rotated/(primary|secondary)

/path/to/rotated/primary
/path/to/rotated/secondary

every n days, primary gets rotated and /path/to/application/password reference gets updated. Every n+45 days, the same thing, but from the applications perspective, it's reference never changes. We have found a way to do this but it's incredibly messy, error-prone, and pollutes the vault space in which we've implemented this concept.

s7an-it commented 1 year ago

I have secrets under IT likes aws keys that I want to utilize from my path without giving policy to see everything else, I want to source up to date with their path key on my end, so links looks quite attractive.

hashicorp / vault