Recently, when building content for one of my upcoming courses, Microsoft Azure Architect Technologies – Exam AZ-300, I found the Microsoft documentation wasn’t immediately clear on the exclusivity of Storage Account Firewalls, and Service Endpoints.
Do I need to use them together, or can they used completely independent of one another?
As always, once we take a look under the hood, and with the help of a test environment, it becomes much more clear just how things actually work.
This article shares some of the key lessons I learnt along the way on such a journey.
Do I need to use Service Endpoints and the Storage Firewall together?
When configuring Storage Account Firewalls, we don’t have to configure a Service Endpoint. Similarly, when we configure a Service Endpoint for storage, it doesn’t require a Storage Firewall rule for the secure/private connectivity to work.
These are two complementary features. Let’s take a closer look at why.
Service Endpoints
If we start with Service Endpoints, it helps to understand that this is actually a property of a virtual network. Here is how we could configure it:
- Create a VNet (vnet1) with one subnet (subnet1)
- Run the CLI command below:az network vnet subnet update -g vnet1rg --vnet-name vnet1 -n subnet1 --service-endpoints "Microsoft.Storage"
Now what we have actually done, is enabled a new default route via the Microsoft backbone; avoiding the public Internet entirely.
If you had a NIC in that subnet and looked at effective routes, you would see something like this:
This means that devices attached to subnet 1 no longer traverse the public internet to get to Microsoft storage.
Tip: Service Endpoints help us to create optimal network routes which use the Microsoft backbone and not the public Internet. One of the benefits of this is improved security, knowing that resources using this feature will connect privately and securely to Microsoft Storage.
Storage Account Firewalls
Next, let’s say we want to protect a Storage Account at the network layer. More specifically, we wanted to restrict access to a specific Storage Account, and only allow trusted IPs. We could do this using Storage Account Firewalls.
Here is an example of how we could configure this:
- Create a Storage Account
- Navigate to the Firewalls and Virtual Networks settings of that Storage Account
- Enable the Firewall by choosing to to allow access from selected networks
- Add whatever allowed IPs we require (or none whatsoever)
When we enable the Firewall, the first change to the Storage Account configuration, is the addition of a default “deny” rule. This can be seen better through Resource Explorer (//resources.azure.com):
Nothing is allowed to access the Storage Account, except either services we exempt, or IP addresses we whitelist. Also, note that we cannot whitelist private IP addresses, only public ones.
Tip: Enabling the Storage Account Firewall creates a default “deny” network rule for that Storage Account, effectively blocking any and all traffic. Traffic can then only be allowed through by either allowing specific VNets, or whitelisting public IP addresses.
Should we use one or both features?
The default deny rule is why the two features can sometimes sound like they are both required to be enabled concurrently. If we do enable the Storage Account Firewall, and still wish for resources within a VNet to have access, then we have two options:
- Making note of the public IP address of our resource, and adding it to the whitelist rules, or
- Enableing a Service Endpoint for the subnet of our resource
However, there is nothing stopping us from using either of the services, by themselves. We can use the Service Endpoint, just for optimized routing, or we could utilizing the Storage Firewall by itself to lockdown network access.
Tip: The key take home-message here is to understand what each of these features actually do. One is for routing, one is for network access control.
If you are looking for more info, feel free to reach out to me in the community, social media, or check out the AZ-300 course recently released in preview. The new AZ-300 Azure Architect Technologies course covers this, and much more.
As always, folks, I hope this helps!