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
{{ message }}
This repository was archived by the owner on Jun 22, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Jun 22, 2026. It is now read-only.
Hello,
I think this would probably require significant work, but are their any plans to add support multiple different configurations? I'm looking to have a non-default Vault using SecretStore that doesn't have a password to be used as part of a module I'm writing to store API keys.
As far as I can tell, if I were to do this now, my module creating a passwordless configuration would prevent the user from being able to have their own, password-locked separate Vault.
Assuming my understanding of the current configuration is accurate, is support for something like this on the roadmap?
Currently, the configuration is per user account, and there is no way to have multiple configured stores per user. I doubt we would change this since part of the security is based on user account isolation. One workaround is to create a separate account for a password-less configuration, for example a test account. But a password-less configuration is susceptible to malicious admin/root accounts.
We have thought about a machine scope based configuration, useable by all accounts. But a password-less machine scope store would not be very secure and I don't know if we would want to support it (unless there was some sort of RBAC).
Thanks Nate Scherer (@natescherer) this is an interesting scenario, that we may want to support in a future release (after GA) but we will have to think more deeply about security implications...cc: Travis Plunk (@TravisEz13)
A global scope is definitely needed in my opinion. As it is now, this doesnt solve anything for my situation. I have on-request processes that need a stored password, but they are executed by various users.
zrbrc (@zrbrc) The -Scope parameter already takes a 'AllUsers' value, but it is not implemented in this first version. But it is something we can look at for the next version release.
Paul Higinbotham (@PaulHigin) Understood, I saw it was there, but unimplemented. I was only commenting bc you weren't sure if that would happen or not. Thanks.
Activity
PaulHigin commentedon Mar 8, 2021
Currently, the configuration is per user account, and there is no way to have multiple configured stores per user. I doubt we would change this since part of the security is based on user account isolation. One workaround is to create a separate account for a password-less configuration, for example a test account. But a password-less configuration is susceptible to malicious admin/root accounts.
We have thought about a machine scope based configuration, useable by all accounts. But a password-less machine scope store would not be very secure and I don't know if we would want to support it (unless there was some sort of RBAC).
SydneyhSmith commentedon Mar 8, 2021
Thanks Nate Scherer (@natescherer) this is an interesting scenario, that we may want to support in a future release (after GA) but we will have to think more deeply about security implications...cc: Travis Plunk (@TravisEz13)
zrbrc commentedon Mar 11, 2021
A global scope is definitely needed in my opinion. As it is now, this doesnt solve anything for my situation. I have on-request processes that need a stored password, but they are executed by various users.
PaulHigin commentedon Mar 11, 2021
zrbrc (@zrbrc) The -Scope parameter already takes a 'AllUsers' value, but it is not implemented in this first version. But it is something we can look at for the next version release.
zrbrc commentedon Mar 11, 2021
Paul Higinbotham (@PaulHigin) Understood, I saw it was there, but unimplemented. I was only commenting bc you weren't sure if that would happen or not. Thanks.
PaulHigin commentedon Mar 11, 2021
We weren't sure how important this was to the community, so your input is valuable and we can make it a higher priority for the next version.