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 that it appears the VMs and keyvault must exist in the same region or I get an error like this:
New-AzureRmResourceGroupDeployment : 9:24:55 AM - Resource Microsoft.Compute/virtualMachineScaleSets 'StdNode' failed with message '{ "status": "Failed", "error": {
"code": "ResourceDeploymentFailure",
"message": "The resource operation completed with terminal provisioning state 'Failed'.",
"details": [
{
"code": "KeyVaultAndVMInDifferentRegions",
"message": "The Key Vault https://obscured.vault.azure.net/secrets/secretname/1112222aa31c4dcca4363bb0013e9999 is located in location West US, which is different from the location of the VM, northcentralus. "
}
] } }'
This feels like an artificial limitation and is a major issue for me. I want to have a centralized keyvault where I deploy all of my secrets and utilize them from all my deployments. Having to duplicate my secrets in regions around the world seems ridiculous and VERY error prone. There should be no significant perf issue here in obtaining secrets across regions. So what is the reason behind this, and will it change?
Anyone from the Azure Scale Sets team want to offer some color to this?
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.