You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: