I\'m working with an ARM template that creates a VM Scale Set for a Service Fabric cluster and associates some secrets with the VMs from a keyvault. I discovered this morning th
To overcome the problem you may simply want to apply a simple fix
Get-AzVM -ResourceGroupName "rg1" -Name "vm1" | Remove-AzVMSecret | Update-AzVM
This will remove the earlier secret and reissue a new one so that your vm is back in provisioning state.
You can use an architecture of a central key vault that you access for template parameters and store those secrets in a regional key vault. Then link to the regional key vault for your scale set. If the secrets are certificates you can have an ARM function to format the certificate (as a secret) properly to be imported as a part of the OSImage property on the VM/VMSS.
A more indepth look can be found here: https://devblogs.microsoft.com/premier-developer/centralized-vm-certificate-deployment-across-multiple-regions-with-arm-templates/
the reason that we enforce region boundaries is to prevent users from creating architectures that have cross region dependencies.
For an application designed like this an outage of the japaneast datacenter will cause your VMSSes in JapanWest to not be able to successfully scale out.
Regional isolation is a key design principle of cloud based applications, and we want to prevent users from making bad choices if we can.
The reason we do not allow cross subscription references is as an important final step to prevent malicious users from using CRP as a privilege escalation mechanism to access other users secrets. There are other mechanisms which also prevent this in ARM, but are based on a configuration.