This is not a showstopper, but I thought I’d mention it in case there’s an easy fix.
When our Azure-hosted PSU instance starts, it does successfully read the secrets from KeyVault, and we can use them in scripts using the $Secret scope with no issues.
However, the Variables page shows a warning icon against them all:
The warning is “This secret does not exist in the vault.”
The only way to remove the warning is to delete one of the secrets from PSU and re-import it from KeyVault.
Again, this is purely a visual glitch - the secrets are there and they work from scripts.
Is there anything I can do to convince PSU that the secrets exist from the get-go? Or is there an easy fix for this?
And now having posted that, I restarted my instance of PSU and suddenly it wasn’t seeing any secrets in the $Secret scope. I deleted a secret from the UI and re-imported it from KeyVault, and it all came good.
So something stops KeyVault secrets from working at startup sometimes. I’m not sure what it is that kicks it into gear.
Can you try adding a Sync-PSUConfiguration -Integrated call to your trigger that configures your KeyVault? The trigger is happening after we loading the variables and it probably is failing to do some validation there. This will cause it to reload the configuration after configuring the vault.
Do you foresee a world in which the -Integrated parameter is implied if the function is executed from inside of PSU? I guess either there’s a technical reason why that can’t happen, or there’s a practical reason why you’d want it to not be the default.
This was actually something we thought of doing when we released v3 but it the integrated mode was still missing a lot of features so it didn’t seem like a good default at the time. So, I do think this will eventually happen and -Integrated won’t be necessary when -ComputerName and -AppToken aren’t specified. It should be able ot figure it out.
I have a similar issue, when mine shows the! , I can’t use any of my secrets. It seems like it starts up and lasts a few hours before the vault gets disconnected. A reboot seems to always fix it.
@adam We just upgraded to 3.2.0, and I am calling Sync-PSUConfiguration -Integrated in my startup script. With the 3.2.0 upgrade the command no longer fails, so that’s the good news. The bad news is that the secrets still have the red “!” icon next to them after the script runs. They work, but PSU doesn’t think they exist.
Also (and this is probably worthy of a new thread but I’ll let you know here) we had to manually create an environments.ps1 file with this version. Looking at my git repository, it doesn’t look like that file ever existed. Once we upgrade to 3.2.0, the endpoints UI wouldn’t load because it couldn’t find the “integrated” environment. I created the file manually and added an integrated environment to it, and now everything seems ok.
I’ll open an issue for these items. Just double checking on the first item: The secrets are working in your scripts etc but they are just listed as not being found?
So directly after upgrading, and after the startup script had registered the vault, I checked the variables page and saw the red warning icons. I then flicked back over to the scripts page and ran a script that uses a secret. It failed. I tried removing a secret from PSU and reimporting it, but the import dialog was empty.
A few minutes later, the same script ran fine, and after that I was able to import the unrelated secret that I had removed.
So something kicks PSU into gear a few minutes after startup. I can’t tell if it’s something I do or if it’s just timing.
Interesting. I really hate how flaky all this is. I think we need to revisit the whole way this is configured to make it more consistent. It’s nice that you can add “any” secret vault but I think we should have a better story for vaults like this. For example, rather than registering the vault effectively outside of PSU via a home grown PS script and a trigger that doesn’t run at quite the right time, we could have a vaults.ps1 or something that allows you to configure a vault and then we can manage the connection etc directly in PSU so it happens at the right time.
New-PSUVault -Name 'MyCustomVault' -Type 'AzureKeyVault' # Additional parameters here
I guess the other thing we do is skip the New-PSUVault cmdlet and just have a vaults.ps1 that runs at the proper time and you can put your SecretManagement calls in there and we can run that at the proper time.
