Allow differently named KV engine paths and a top level secret directory other than `vaultPass` -- Or drop the requirement entirely and have vaultPass dynamicly scan for kv engines and secret paths at user login?

[ipaqmaster]

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

When we have existing kv secret engines for our organisazation and now need to consider migrating every single website credential set to a new kv engine named secret and under a subpath named vaultPass

Describe the solution you'd like It would be outstanding if vaultPass simply has an extra text field, maybe under its options tab underneath the Auth Mountpoint string, asking for the kv engine name to use and optionally also the top level secret path to use.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Automatic scanning of all KV secret paths a user has access to when they click Login to Vault, instead of requiring secret/vaultPass to exist

Additional context Add any other context or screenshots about the feature request here.

I understand at a glance this is a pretty tall order; I hope at least adding text fields to overwrite the kv/ engine path name and /vaultPass top level directory name requirement inside would not be too difficult.

Replacing this entire system with a dynamic kv engine and inside path scan at user login would be a lot more and different work, but would also help this project flourish in any environment.

(Considered adding /totp support as well?)

[mulbc]

This has been requested often enough, that I still wonder how you end up with website secrets in your Vault before VaultPass (given that there's no other Vault-based password manager?!) - but I see the need to have the path configurable.

I'll see when I have the time to add that field to the login page.

[ipaqmaster]

It's a good point, but unfortunately organizations exist where staff access well-known but well-kept third party secrets using Vault, but not necessarily in this extension's path. Though personally I'm happy to have Vault instead of classic approaches such as Keepass, or a modern third party hosted solution off premises regardless.

It makes things tough given Vault itself doesn't support any form of "Moving" or at least "Aliasing" (Thinking a form of symlink) existing written kv secret paths under a different path without programming some outsider API loop to read and re-write them all elsewhere before deleting originals (Barbaric at scale). It would certainly help make vaultPass be more plug n' play regardless of Vault layout organization to organization.

It's a tall order and just theory, but it would be idea if vaultPass could take any set of valid credentials for any Vault cluster and just enumerate the available KV mountpoints to the user and enumerate through them for fqdn's with username and password data. It would become pretty foolproof for any existing setup, but again it's easy to type a paragraph but would be a huge change to vaultPass to implement. Another Vault tool, Cryptr, seems to handle secret indexing this way. Just rolls through everything your account's ACL(s) have access to.

I suppose if somebody really wanted vaultPass to work on their organization's existing secrets without contributing or waiting, they could transparently rewrite the request's on a reverse proxy. Probably some extra hitches to consider when doing that though.

[mulbc]

Valid points and that's why I will add it in time ;) Thanks for taking the time to explain - out of curiosity is your company thinking of or actually using VaultPass yet?

[mulbc]

@ipaqmaster - just FYI - we have this now and I just packaged a new version and pushed it to the Chrome & Firefox stores for review: https://github.com/mulbc/vaultPass/releases/tag/v2.3.3

[ipaqmaster]

Thank you very much for adding this. I'm confident everyone else will appreciate the option too!

[nemcikjan]

@ipaqmaster - just FYI - we have this now and I just packaged a new version and pushed it to the Chrome & Firefox stores for review: https://github.com/mulbc/vaultPass/releases/tag/v2.3.3

The issue is not solved for token grabber functionality. Getting following error:

Uncaught (in promise) Error: Fetching list of secret directories failed: {"errors":["1 error occurred:\n\t* permission denied\n\n"]}

It would be great though to add options to login to vault with different auth methods than userpass, but cannot estimate the efforts to implements this.

[mulbc]

This error is actually thrown after the Vault token has been fetched. It is thrown when the extension tries to list all the VaultPass organisations that have secrets in Vault.

It is possible that this hint at miss-configured Vault policies that prevent your user from issuing a LIST operation at ${vaultServerAddress}/v1/${storeComponents.root}/metadata/${storeComponents.subPath} --> Usually that directory is https://yourVault/v1/vaultPass/metadata/

Are you able to check that?

[ipaqmaster]

I'm glad this change has been made but I'm watching the plugin make not GET requests but LIST requests to the vault cluster against the secret paths themselves (Not a directory of secrets but the secret itself) and receiving a 404 as a result then putting a strikethrough on the secret name.

With the CLI doing a vault list against the same path throws "No value found" as well which is correct and consistent as it's not a directory of secrets, it's the secret. The directory it's in is valid for a list but the secret itself must be read