Member-only story
One single vulnerability is all an attacker needs ~ Window Synder
Azure VNet service endpoint enables secure connectivity to Azure resources(azure storage, azure SQL server...). Plus, it also constrains traffic flow over the Azure backbone network instead of the public internet.
Resources inside service endpoints can communicate using their private IP address (public IP addresses earlier)with endpoints enabled.
Azure resources that support service endpoints can now set up firewall rules to allow traffic from only the necessary VNets, restricting traffic and enhancing security.
And of course, as mentioned earlier it prevents creating additional public IP addresses for resources. Earlier, IP based firewall rules required public IP assignments.
We can create only one service endpoint per subnet in a VNet.
These service endpoints cannot be used for connectivity from on-premise to Azure resources, it's only for Azure-to-Azure communications.
Already existing public IP based firewall rules(for any resource) will stop working, once the resource starts using service endpoints. These need to be updated to use private IP addresses instead(probably before switching to service endpoints)
Here is a very concise representation of how a service endpoint can be set up to secure Azure -resources.
As we see above, a service endpoint is configured for subnet — 10.1.1.0/24 in the VNet address space 10.1.0.0/16. Azure storage account supports service endpoint, hence a firewall rule could be created to allow traffic from the service endpoint only. All communication happens on the internal Azure backbone network now.
Here is how we can configure a service endpoint in Azure and create an “Allow” traffic rule only from that subnet in Azure storage.
I have already created a virtual network with the address space 10.0.0.0/16 with two subnets in it.
