Azure private link / endpoints allow you to connect resources to your private virtual network and with that - when removing public access - shield ...
For further actions, you may consider blocking this person and/or reporting abuse
added March 2023 addendum - Blob Triggers in container hosted Azure Functions
Hi Kai,
Great post! Thanks for sharing!
Did you create multiple DNS Private Zones for the same resource for each regional VNET?
As per my understanding Microsoft recommends creating one single Private DNS Zone as suggested here. You can link that Private DNS Zone with multiple VNETs as described here
This way you can manage all your Private Zones in one resource group. Unless you faced any limitations with that approach?
Look forward to your thoughts :)
Hello Paco,
right, for most of the resources - which have a unique name within a region and hence a unique IP address - I created one private DNS zone and linked that to multiple VNETs. For the 2 in our environment "global" resources like CosmosDb and Container Registry, which are linked into all regional VNETs and with that have different IP addresses for the same "global" name, this did not work. I did add same name with multiple IP addresses into the one private DNS zone for e.g. CosmosDB, but with that resolution and accessing the service was not possible - our VNETs are not cross-connected and there was no way controlling that always the correct "local/regional" IP address was resolved. Hence the approach that for these global resources I have regional private DNS zones with the proper local/regional IP address.
Does this make sense? Maybe I overlooked something here but I was really checking docs and also haunting MS support :-)
-Kai
It does make sense. Thanks for clarifying Kai!
woooww, you blog blasted my brain! ;) thanks kai for sharing this real life insights and learnings in enterprise-scale challenges with azure. one questions came to my mind on reading: Does access/management to the secured resources via portal.azure.com still work in this scenario with service/private links ootb across the network boundaries? Or do you have even no more need to use portal.azure.com (eg. use the portal-storage explorer to check blobs in storage..) for administration in this scenario?
Thanks JJ!
Indeed implementing access management - if you refer to IAM - is one of the next things I will add to this setup - so right now I cannot tell. Right now devs do not have access to this environment anyway and admins would use jump VMs - for Portal, PowerShell and CLI.
Also we use a script which an admin can use to link his/her own VM to the enviroment. Storage Explorer, Data Explorer, etc. I do not want to be available in publicy accessible Azure Portal.
added another post how I added IAM to the solution : dev.to/kaiwalter/getting-started-w...
for me these are totally independent - with IAM you restrict people being able to create or modify Azure resources and with private link you restrict access to the resources data (SQL, CosmosDB,Storage,ACR) or functionality (AKS,ACR,ServiceBus)
to be able to read the contents you would need to have a peering from where you come (Tunel or Express Route) and let your (I assume on-prem environment) also know about the Private DNS Zones in Azure. Here is a nice doc from msft how this can be handled: docs.microsoft.com/en-us/azure/pri...
added limitation of ACR build in private link setup
How do you handle private-link names for keyvault if having a single privatelink.vaultcore.azure.net dns-zone? They would be clashing.
What do you mean by "clashing"?
If I would have to produce the same DNS record but with different IP addresses (like for Cosmos DB multi-regional) I would have private DNS resource spreaded over multiple (regional) resource groups and only assign relevant private DNS resource to the appropriate VNET.