Allow VM Extensions to communicate via 168.63.129.16 to Storage and Key Vault
Currently, VM Extensions require access to Azure Storage and/or Key Vault in order to function, and according to MS Support, this is achieved via the internet on port 443.
For IaaS solutions where generic internet traffic is blocked (which seems to be agreed best-practice) Custom Script deployments can occasionally fail, and all subsequent ARM deployments fail.
The 'solution' to allow port 443 traffic out of the VMs isn't a viable one for secure solutions, neither is white-listing the Storage and/or Key Vault URLs, being s that's not possible in Windows Firewall, NSGs, or Routing Tables, forcing the use of costly third-party Firewall Appliances.
It would be considerably simpler for deployment purposes if these extensions communicated with Storage and Key Vault via the pre-existing virtualized host IP address of 168.63.129.16 already used for DHCP, DNS etc.
Andrew Herbert
shared this idea
2 comments
-
Marcel Paap
commented
Please fix this. Gives a lot of challenges with our IaaS deployments.
-
JH
commented
I agree, outbound internet access should not be a requirement for VM Extensions in general.
It would also help if we could run a simple Post CMD during deployment (similar to CMDLINES.TXT in the old days), for example to setup connectivity (e.g. Proxy)