What does this tooltip mean? The secret is definitely working - I have a script that’s using it.
Weird. When we load the variables we run some PowerShell to check to see if the secret is actually in the vault. That must just be bugged in certain scenarios. I’ll open an issue and any logging might be handy to have.
EDIT: Secret marked as does not exist when it exists · Issue #727 · ironmansoftware/issues · GitHub
1 Like
Oh this turns out to actually be a problem, and maybe not just a UI glitch.
After restarting our Azure Web App to try to cancel a job, I’m now getting $null values for our secret variables.
So it’s almost like they persisted in memory and that’s why the UI was reporting that they weren’t in the vault.
Anything I can provide to help fix this one?
Yeah I can see in the logs messages like “The secret was not found.” Presumably they were written there at app startup.
Secrets are stored in Windows Credential manager which much not persist on restart. Seems like we will need to implement a more cloud friend (Azure Key Vault probably) solution.
1 Like
The SecretsManagement module uses its own vault (rather than the Windows built-in vault) by default, right? Could you use that instead? I’m not sure where that persists, or whether it’s possible to customise its persistence layer so that Azure Web Apps work with it. Might be an easier fix than switching to Key Vault? Just spitballin’.
We use the Microsoft Secret Managment module which uses Credential Manager by default. That said, we are using the old version of the module and the new version uses some other persistence types and I think other providers. We have implementing the new version in the backlog. I’ll bump it into our 2.6 or 2.7 release so we can start to use the new providers.
Hmm. I thought it used “SecretStore” by default:
PowerShell/SecretStore (github.com)
I know SecretStore is supposed to be cross platform … but is that using the Windows credential vault if it’s on Windows?
Nah. It uses this module which defaults to the Windows Credential Vault on windows.
Hmm I was tracking the SecretManagement project while it was in preview release but haven’t looked recently. Originally the SecretManagement module didn’t do anything by itself - you needed to install a “vault” first, and the default “vault” was the cross-platform SecretStore module. There was a “CredMan” module that was for the Windows built-in vault.
That was the second iteration of the secret management module. We are actually using an even older version.
The problem was we integrated with the secret management module and then they completely redid it so the interface was completely different. We were waiting for it to stabilize before doing another integration because we messed up by adopting the first iteration so early.
It’s definitely time to get the new version integrated.
1 Like
Actually with the “vault plug-in” model of the final version SecretsManagement, I could picture you having a nice configuration page where the admin could add/remove vaults (effectively just installing modules) and set a default per environment!
1 Like
Again, this is another conversation I would have found myself having at some point, it would be awesome to use different providers with the secret management module for sure.
I didnt know if there was already a way to do that or not within PSU, but my end goal with our azure deployment would be hooking into existing keyvaults, also possibly even cyberark too if we needed.
1 Like
2.6 will include support for the 1.1.1 version of the Microsoft.PowerShell.SecretManagement module which has support for other providers (including Cyberark).
2.6 won’t have any UI for configuring vaults but you should be able to set them up on the PSU machine. I still need to think about how to properly unlock a vault within PSU.
1 Like
Do you think the mechanism by which the vault is “unlocked” will make it into 2.6? Or will we be manually unlocking the vault and retrieving secrets from it in any script that needs them?
I think an appsetting/env var for the vault password (similar to the JWT signing key) would be fine. Like I said on Twitter, it’s definitely a chicken/egg thing.
I’ll add an appsettings.json setting for this in 2.6 so that we at least have a vault that will work in Azure and non-Windows systems using the SecureStore vault.
You’ll be able to override it with environment variables in your Azure environment like other settings. For other vault types (Azure Key Vault etc) it would take manually unlocking the vault at the moment.
1 Like