I have a bunch of scripts that get called by endpoints using the invoke-subscript, and I have noticed some slowness in some of my scripts.
I have been starting to experiment with the profiler module, and I was wondering if anyone else has used it.
One thing I noticed in my script is that the longest process was fetching secrets.
@adam, do you have any idea why retrieving a secret via the $secret scope could take that long? this is latest version of 4 using the default litedb setup.
I think its worth mentioning, this secret is stored in azure keyvault which might be why lol
Ahhh ok. I was going to say there’s no way it should be that slow in the database but that would be more sense. That said, 1.9 seconds is super slow! Could it be network or is it just on the Azure end?
I wonder if there is a way we could still have our secrets in Azure but have PSU store the secrets locally in the DB by doing a sync?
Top stopwatch is from reading secret in azure.
Bottom one is from reading a local secret.
Whoa. Wild.
You could setup some sort of scheduled task to do so. Like:
$Val = $Secret:MyAzureSecret
New-PSUVariable -Name ‘MyLocalSecret’ -Value $Val -Vault ‘Database’ -Force
Then use $Secret:MyLocalSecret locally. I do think it changes the security model a bit by copying them locally, but I think that’s up to you to determine if that’s right for your org.
The only downside to this is that it duplicates the vars.
I guess we could have something in the initialize.ps1 that creates these vars and another process that handles the sync.
Can you elaborate on what you mean by security implications?
I think the route I want to take once we migrate to SQL in our production environment is to have the secrets stored locally rather than reach out to Azure for them.
Mostly just suggesting that they are stored locally rather than in the cloud which could be against company policy. If it’s not then, no reason to worry about it. Especially if you plan to just store them locally in the DB.