Azure Service Endpoints
The course is part of this learning path
This course will focus on how to create and configure Azure service endpoints so that PaaS services can be made available from within your virtual network. The course will also discuss service tags, their association with service endpoints, and how to use them within the scope of your Network Security Groups and Azure Firewalls to allow/deny traffic to Azure PaaS services. The course will help to put all of this information into perspective.
- Create service endpoints
- Configure service endpoint policies
- Configure service tags
- Configure access to service endpoints
- Azure Network Engineers who will be recommending networking solutions and managing them for performance, resiliency, scale, and security
- Azure Network Engineers who will be working with solution architects, cloud administrators, security engineers, and application developers to deliver Azure solutions
- Subject matter expertise in planning, implementing, and maintaining Azure networking solutions, including hybrid networking, connectivity, routing, security, and private access to Azure services
- Azure administration skills
- Experience and knowledge of networking, hybrid connections, and network security
Hi there. In this video, we're going to talk about something a little bit different but that is directly tied to service endpoints and that is service tags. Now, what exactly are service tags? They are a group of IP addresses and specifically the prefixes for an Azure service. So if you're using Azure app service, if you're using Azure storage, if you're using Azure key vault Microsoft has provided public endpoints. CNAMEs, IP addresses, related to that service within the scope of your region. You deploy the same service in a different region, you're going to get a completely different set of IP addresses. The service tags correspond to the IP addresses or specifically the ranges the prefixes of those IP addresses that are associated with a specific service in that region.
They replace the service tag itself is basically nothing more than a name that replaces the IP addresses. For security rules in network security groups Azure firewall, they support a regional scope as I just talked about because they correspond to only the IP addresses of the service in that particular region. So there's going to be a different set of IP addresses behind that service tag for a different region and they can be used in both in inbound and outbound access. They can also now be used in public preview uh for user-defined routes as well.
Now, a quick example and I'll actually do a quick demonstration of this as well. This is what a service tag would look like within the scope of a network security group and its corresponding rules. If you'll see here in the image on the right-hand side. There are two allow rules and a deny rule. The deny rule is the standard one that you find in every network security group but the top two allow for traffic from a virtual network IP address. Hence the virtual network service tag to a storage as well as sequel in East Us, both storage and sequel East Us our service tags that correspond to those respective services. Virtual network also corresponds to a service tag within the scope of your specific subscription. Now let me jump over into the Azure portal.
We'll quickly just so that we can actually see this live here. We are in the Azure portal. I already have a network security group created and this is just a Default one. I have also already applied this to the subnet that we created in the previous videos that has storage and key vault as valid service endpoints. So what I'm going to do is I'm gonna create an outbound rule for the virtual network to allow for traffic to go from any IP address in the virtual network into that particular storage class. So what I will do is go to outbound security rules. I will click add the source is going to be a service tag and it's going to be specifically the virtual network. So I'm using the service tag in my source field.
I'm gonna leave sore sport ranges as an asterisk and that's something I typically do anyway. The destination then will also be a service tag and in this case because if you'll remember we configured storage as one of the service endpoints, I'm gonna choose storage here And I'll just do a quick search for it there it is. You'll notice I can either choose storage globally, thereby allowing for access to any storage service or I can focus on just this particular region which is east us two, and then we can specify destiny destination port ranges and the rest of the pieces are tied to a network security group but that's how you can leverage service tags within the scope of a security rule. And again, these security rules can be applied in a network security group or in Azure firewall and now in public preview, they can also be leveraged inside of user to find routes. So let's jump back into the powerpoint.
Now there is a very large list of available service tags that are available within the scope of Azure So many that I could not put them on three slides, let alone one. So here is the URL. That I'm gonna be showing you here in a second. I wanted to make sure that you had an opportunity to see this, write it down, go into your own browser yourself. Now let me show you this list. Okay, here we are in this exact documentation page and this is the available service tags listing uh they do support regional scope and can be used in Azure firewall rules as we already talked about. But this is the entire list and it starts from up here at action groups which are tied to Azure alerts in case you're interested and goes all the way down to virtual network that we just saw me use. But this is the entire list of service tags that Microsoft has made available. These are out of the box. Every customer has them. You don't have to worry about doing any kind of configuration.
It's just up to you to use them as you see fit within the scope of your security rules. Now, one additional feature of service tags is that you can actually use them in your on-premise environments. If you have a hybrid network set up where you are using say express route, for example, to take advantage of access to Azure past services and you want to make sure that no other traffic is flowing out to as you're you only want traffic to flow to those specific services. You can lever leverage service tags in your on-prem environments as well. They can The service tag information can be used in your on-premise firewalls, for example, the service tag information that you're going to be gathering is going to be a current point in time list of IP ranges. That list can change over time. So you're probably gonna want to create an automated process to keep your data up to date based on the information that I found in the documentation.
It can be updated on average once an hour. The data for the service tags, in other words, the IP address listings can be obtained programmatically or via adjacent download the arrest APIs. Power shell and Azure cli here is a quick example using Azure power shell to get the network service tags from a specific region in this case East us two we store the data into the service tags. Then we want to get out just the information related to storage because getting all of the service tag information we just saw that's going to be a very very large list. But if you're only worried about controlling traffic to a specific service, you only really need the information for that service.
In this case, it's going to be storage and then we're going to be able to get the address prefixes and use that data within the scope of any particular firewall device that you might happen to have. Now there are some gotchas here that you need to be aware of. It can take up to four weeks for new service tag data to propagate within the api results across all Azure regions. Something to keep in mind again based on what we just saw, you're probably going to want to keep an automated process in place so that you can make sure that the data in your firewalls are always up to date. And most firewalls do have some kind of shell scripting capability, python scripting capability for you to be able to do that, you must be authenticated and have a role with re permissions within the scope of your current subscription to be able to get this data.
So you saw that Azure power shellcode, you did not see the login command that was run first in order to actually authenticate against a specific Azure subscription. The API data represents the tags that can be used with NSG rules which represents a subset of the tags currently in the downloadable Jason file. One of the things to keep in mind is there are service tags that are outside of the scope of security rules that can be leveraged in other places or that Microsoft themselves use internally the Jason file contains everything.
Whereas the programmatic Azure power shell, Azure cli and rest APIs only propagate the ones that are relevant to security rules and that's really all that there is for service tags I say, all that there is service tags themselves are a very very small feature but the amount of data that's available and the use of that data for you as a customer is extremely large, you can use it all across the networking inside of Azure and as we've now just seen, we can use it outside of Azure in your on Prem environments as well.
In the next video, we're going to take a look at how to configure access to your service endpoints so that we can actually lock things down and validate that people have the correct access.
Brian has been working in the Cloud space for more than a decade as both a Cloud Architect and Cloud Engineer. He has experience building Application Development, Infrastructure, and AI-based architectures using many different OSS and Non-OSS based technologies. In addition to his work at Cloud Academy, he is always trying to educate customers about how to get started in the cloud with his many blogs and videos. He is currently working as a Lead Azure Engineer in the Public Sector space.