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

Allow indirection in secret names w/ secret-fetcher #410

Open
spladug opened this issue Mar 11, 2020 · 1 comment
Open

Allow indirection in secret names w/ secret-fetcher #410

spladug opened this issue Mar 11, 2020 · 1 comment
Labels
needs design this is probably a big enough topic to need a design doc

Comments

@spladug
Copy link
Contributor

spladug commented Mar 11, 2020

Currently, the application and secret fetcher both use the full Vault paths to secrets. This tightly couples them to the exact names of those secrets in Vault.

Instead of taking a list of secret names to fetch, the fetcher should instead take a mapping of local name->vault name. When it fetches down the secrets by vault name, it writes them out to the secrets file using the local name. Applications could then reference the secret using a local name that's decoupled. No changes would be needed in the SecretsStore API since the names would just be transparently different.

Ideally it could recognize both forms of config for backwards compatibility which would make this effectively an opt-in change.

@spladug
Copy link
Contributor Author

spladug commented Mar 11, 2020

Credit to @eaceaser for the suggestion/request.

@spladug spladug added the needs design this is probably a big enough topic to need a design doc label Nov 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs design this is probably a big enough topic to need a design doc
Development

No branches or pull requests

1 participant