Mounting to an existing path in Vault

[mmckane]

It seems this requires access to sys/mounts as its creating and deleting the entire secrets store in vault.

It would be nice if this could also mount to existing secrets stores in vault created and managed by a vault administrator in addition to removing the need for privileged access to sys/mounts. Adopting this library will be hard for organizations with existing vault implementations without this feature.

Also thinking through how this is setup now, if I wanted to use this module for a team of people to access credentials across multiple machines is hard because I can't re-mount the secrets store from vault on a second machine currently because I have no way to access the secrets store created by the other machine or even other user.

Also not a huge deal, but troubleshooting what was happening was difficult because there doesn't seem to be any user feedback when the Test-SecretVault was getting a permission denied on v1/sys/mounts endpoint. I would just get False even with verbose on, not sure if this can be fixed with the way the module is wrapped by secretsmanagement but it was frustrating.

[joshcorr]

Thanks for the issue and feedback.

So to break this down a bit so I can look to fix.

• [ ] Remove reliance on sys/mounts (if possible)
• [ ] Attach to existing (HashiCorp) vault
• [ ] Give better feedback on Test-* functions.

That look right?

[mmckane]

Remove reliance on sys/mounts (if possible):

I had some more time and dug further into what is happening in my environment and was able to get read/list /sys/mounts access from the vault team,, and got my calls working, but fell over on the sys/health calls. Our vault admins are hesitant to open up this access to everyone for some reason. It might make more sense if this is optional, if I want this module to create everything for me in vault great you need sys/mounts access, otherwise if you are mounting an existing path possibly don't require it if that is possible to test and add.

Attach to existing (HashiCorp) vault

It looks like you might support this already now that I have had more time. This might just be a documentation thing, it looks like it should just be Register-SecretVault -ModuleName SecretManagement.Hashicorp.Vault.KV -Name <name of existing vault path>

Give better feedback on Test-* functions.

From what I was poking at if one of the invoke-restmethods in the api functions gets a status code other than 200 the Test-SecretVault throws an exception with little to no info on what the issue was or how to fix it.

/sys/health issues =(

There is actually another issue specifically here We have an HA Vault setup and when you hit /sys/health it can return codes other than 200 we get a code 473 notifying the user its a performance standby node instead https://www.vaultproject.io/api-docs/system/health when this happens invoke-restmethod treats it as a fatal exception and ends up in the catch block here

On Powershell 7 there is a -skiphttperrorcheck but obviously this would break all older version of powershell.

[mmckane]

PS I did sort of get this working with -skiphttperrorcheck on that one invoke-restmethod but ran out of time today to fully test it. I can create a PR for that if you want but I am guessing you would like to target older versions of powershell too.

Also great work so far @joshcorr this will be really useful for securely running powershell scripts everywhere.

[joshcorr]

I would like to support PowerShell 5.1 as it is the minimum version supported by the Microsoft.PowerShell.SecretManagement module. The Invoke-CustomWebRequest function is handling all Invoke-WebRequest like functionality (some functionality) and could be modified to provide the same option as the v7 switch, but the Vault code should probably handle the HTTP errors a little better in the places you mentioned.

Seeing it now, creating a vault should be the fall back instead of the default. It was a bit shortsighted by my own experiencing of administrating and using vault (non HA setups). Will try to get another version out there before the weekend to test out, but PRs are more than welcome as well. 😊

[joshcorr]

Give the new Preview build a spin, and let me know if it works better for you.

1.0.1-Preview

Because of the nature of SecretManagement there is no way to raise a native error from the extension, so I went with warnings. The warning will prompt every time since the Test-* function needs to run before each call to Vault. In the future this test may also check the health of the Token to ensure it is still active, or if it needs to be renewed, etc.

[joshcorr]

@mmckane any luck with that new version? or the 1.0.2-Preview version?

[joshcorr]

I am able to connect to existing vaults using this extension. If there are still problems please open another issue.