Hey all,
We use integration with KeyVault to pull secrets into PSU as variables (which works fine everywhere else), however if I try to use a $Secret:VariableName in a policy script, it doesn’t seem to look up the variable.
It looks like the security environment by default uses integrated, which is the same as scripts, dashboards etc so I would’ve thought it should work.
Does anyone have this working?
Thanks,
Tom.
Product: PowerShell Universal
Version: 4.0.11
While I havent personally tried this, I used to use keyvault, I had a script which did the following:
It was set to run on server startup but with a delay of 20 seconds - purley to allow time for everything else to fire up.
I wonder if it’s something similar, or to do with the order of how things are initialized that is causing your problem.
I did see recently adam released a docker image with az modules (keyvault) included so it was more efficient to use keyvault as the secret store, I would give that a try if you havent already and are currently running with docker.
Another thing to do would be to put some sort of output, maybe trying to use ‘Get-PSUVariable | ConvertTo-Json | out-File’ in your role, so that you can inspect the file after the role has executed and see if any of the variables are being spat out, not just keyvault ones, or if it’s specific to keyvault.
Getting KeyVault secrets through variables works everywhere else, it seems to just be role policy scripts. My colleague @Matt.Harris had a good point though, it’s probably by design as the user isn’t authenticated at that point and would be pulling potentially secret or sensitive information. There does seem to be a way around this though by running get-AzKeyVaultSecret and getting the value directly from KeyVault itself which does work (in case anyone else needed to do this).
I have been thinking about these processes.
@insomniacc: The new ‘Modules’ Docker image is a requested docker image which contains AZ.KeyVault, AZ.Accounts, Invoke-SQLcmd2, and a few others. By placing KeyVault and Accounts in the /home folder structure as opposed to the /root folder, you are able to connect to azure via service principal and setup/pull KeyVault secrets at boot (Before anything is pulled from the /root folders section).
The load-up times are massively improved, and this worked weirdly well out of the box. I spent more time making sure it actually worked then setting it up, deleting almost all of my workaround code. Using this method, I was able to remove all of my code from involve.ps1 script.
Feel free to reach out if you would like to know more about this, and I shall write something up. Documentation for the new Key vault and accounts mechanism has been briefly documented here.
If there is a request, I will write up more of a guide about this new ‘Modules’ container and how to set up KeyVault support out of the box. Having these modules load up at his phase of the boot process massively opens up new avenues of options of what we can do with the PSU Linux container without painful manual workarounds.
Regarding the reference made by @tom.obrien. At about 10 mins before the end of the day on Friday I suggested that roles’ authentication process may load before KeyVault pulls its secrets. This would make sense, as you kind of sort out your security and permissions before anything else.
I will have to confirm with @adam if this is the case. If it is, then it should be easy to work around in the correct manner.