Vaults.ps1

[adamdriscoll]

Summary of the new feature / enhancement

We need a way to more consistently ensure that secret vaults are registered. In some environments, like Azure, the secret vault registrations aren't persistent between restarts of the web app. This leads to having to schedule triggered scripts at startup and then hope that they finish at the right time before variables are read.

With a vaults.ps1, we could also add a new UI page to view registered vaults, their vault types, parameters used to configure them and the count of secrets available. We could also make it so you could manage secrets in the vaults (add, delete, etc). We need to make sure it's clear that a variable is still required (maybe a create variable button?) for scripts to use secrets.

I'm considering not introducing a new cmdlet for vaults but to use the SecretManagement cmdlets to list and manage vaults. We should be able to get all the info we need from those cmdlets.

Proposed technical implementation details (optional)

No response

[adamdriscoll]

This issue has been mentioned on Ironman Software Forums. There might be relevant details there:

https://forums.ironmansoftware.com/t/azure-keyvault-secret-variables/7423/12

[mabster]

Loving this idea more and more. Azure restarted our app service unexpected last night, and when I got in this morning, none of the morning's scheduled scripts had run successfully 'coz they couldn't get to our secrets. An official "vaults.ps1" that runs at the appropriate time to register the KeyVault would give me some peace of mind! :)

Obviously registering the KeyVault as a vault means you need to be connected to Azure ... would the Connect-AzAccount call occur within vaults.ps1, or do you have other ideas on where that could happen?

[adamdriscoll]

@mabster - Yeah. I assuming Connect-AzAccount would happen in the vaults.ps1.