Azure Firewall and Service Endpoints
In my recent blog series Private Link reality bites I briefly mentioned the possibility of inspecting Service Endpoints with Azure Firewall, and many have asked for more details on that configuration. Here we go! First things first: what the heck am I talking about? Most Azure services such as Azure Storage, Azure SQL and many others can be accessed directly over the public Internet. However, there are two alternatives to access those services over Microsoft's backbone: Private Link and VNet Service Endpoints. Microsoft's overall recommendation is using private link, but some organizations prefer leveraging service endpoints. Feel free to read this post on a comparison of the two. You might want to inspect traffic to Azure services with network firewalls, even if that traffic is leveraging service endpoints. Before doing so, please consider that sending high-bandwidth traffic through a firewall might have cost implications and impact on the overall application latency. If you still want to go ahead, this post is going to explain how to do it. The Design Service endpoints have two configuration parts: Source subnet configuration to tunnel traffic to the destination service. Destination service configuration to accept traffic from the source subnet. The key concept to understand is that if traffic from the client is going to be inspected by a firewall before going to the Azure service, then the source subnet is actually the Azure Firewall's subnet, not the original client's subnet: You can configure service endpoints for a specific Azure service on a subnet using the portal, Terraform, Bicep, PowerShell or the Azure CLI. In the portal this is what it looks like: For Azure CLI, enabling service endpoints for Azure Storage accounts in all regions would look like this: ❯ subnet_name=AzureFirewallSubnet ❯ az network vnet subnet update -n $subnet_name --vnet-name $vnet_name -g $rg --service-endpoints Microsoft.Storage.Global -o none --only-show-errors You would then configure your Azure services to accept traffic coming from the Azure Firewall subnet. For example, for Azure Storage Accounts this is what you would see in the portal: Network Rules or Application Rules? Ideally you should use Application Rules in your firewall to make sure that your workloads are accessing the right Azure services, and not exfiltrating data to rogue data services that might be owned by somebody else and still could have the same IP address. This is an example of a star rule granting access to all Azure Storage Accounts, but you should specify your own: I tested with two storage accounts, one in the same region and another one in a different region than the client (the client being in this case the Azure Firewall). Access to both storage accounts is working, and as you can see both accesses are logged in the Storage Account as well as in the Azure Firewall (I have removed some characters from the storage account names to obfuscate them): ❯ ssh $vm_pip "curl -s4 $storage_blob_fqdn1" Hello world! ❯ ssh $vm_pip "curl -s4 $storage_blob_fqdn2" Hello world! ❯ query='StorageBlobLogs | where TimeGenerated > ago(15m) | project AccountName, StatusCode, CallerIpAddress' ❯ az monitor log-analytics query -w $logws_customerid --analytics-query $query -o table AccountName CallerIpAddress StatusCode ---------------------- ----------------- ---------- storagetest????eastus2 10.13.76.72:10066 200 storagetest????westus2 10.13.76.72:11880 200 ❯ query='AzureDiagnostics | where TimeGenerated > ago(15m) | where Category == "AZFWApplicationRule" | project SourceIP, Fqdn_s, Protocol_s, Action_s' ❯ az monitor log-analytics query -w $logws_customerid --analytics-query $query -o table Action_s Fqdn_s Protocol_s SourceIP --------- -------------------------------------------- ---------- ---------- Allow storagetest????eastus2.blob.core.windows.net HTTPS 10.13.76.4 Allow storagetest????westus2.blob.core.windows.net HTTPS 10.13.76.4 The storage account sees as client IP the Azure Firewall's IP (in the subnet 10.13.76.64/26), and the Azure Firewall logs show the actual client IP (in the workload subnet 10.13.76.0/26). If you use network rules you would lose a lot of the flexibility of the Azure Firewall, even if using FQDN-based rules. The reason is that if there were 2 storage accounts with different FQDNs sharing the same IP address, and the same client resolves both FQDNs, when Azure Firewall looks at the packet it will not be able to guess to which storage account each specific packet belongs to. From a routing perspective it would still work though, as long as you have the default SNAT settings of Azure Firewall, which involves translating the IP address when public IP addresses are involved: Conclusion There are some reasons why you might want to pick VNet service endpoints over private link (cost would probably be one of them). If so, there are advantages and disadvantages of sending traffic to Azure services via a firewall. If you decide to inspect traffic to VNet service endpoints with Azure Firewall, hopefully this post has shown you how to do that. What are your thoughts about this?Azure Private Endpoint vs. Service Endpoint: A Comprehensive Guide
When building secure and scalable applications on Microsoft Azure, network connectivity becomes a critical factor. Azure provides two primary methods for enhancing security and connectivity: Private Endpoints and Service Endpoints. While both serve to establish secure connections to Azure resources, they function in distinct ways and cater to different networking needs. This blog will explain the differences between the two, their use cases, and when you should use each. Understanding Service Endpoints Azure Service Endpoints allow you to securely connect to Azure services over an optimized route through the Azure backbone network. When you enable service endpoints on a virtual network, they extend the private IP address space of that virtual network to the service. Essentially, they provide a direct, secure connection to Azure services like Azure Storage, Azure SQL Database, and Azure Key Vault without requiring the traffic to traverse the public internet. Key Characteristics of Service Endpoints: Public Services, Private IP: Service endpoints allow traffic to go through the Azure backbone but still access services using their public IP addresses. However, the traffic is not exposed to the internet. Network Security Group (NSG) Integration: Service endpoints can be secured using NSGs, which control access based on source IP addresses and subnet configurations. No DNS Resolution: Service endpoints use public DNS names to route traffic. Thus, the service endpoint enables network traffic to be routed privately but relies on public DNS resolution. Use Cases for Service Endpoints: Simplified Security: Service endpoints are ideal for connecting to Azure services in a straightforward manner without needing complex configurations. Lower Latency: Since traffic is routed through the Azure backbone network, there’s less congestion compared to public internet traffic. Integration with NSG: Service endpoints allow for tighter security control with Network Security Groups, ensuring only approved subnets and virtual networks can access specific services. Understanding Private Endpoints Private Endpoints, on the other hand, provide a direct, private connection to Azure resources by assigning a private IP address from your virtual network (VNet) to the service. Unlike service endpoints, which rely on public IPs, private endpoints fully encapsulate the service in a private address space. When a service is accessed via a private endpoint, the connection stays within the Azure network, preventing exposure to the public internet. Key Characteristics of Private Endpoints: Private IP Connectivity: Private endpoints map Azure resources to a private IP in your VNet, ensuring all traffic remains private and not exposed to the internet. DNS Resolution: Private endpoints also require DNS configuration so that the private IP address can be resolved for the associated Azure service. Azure offers automatic DNS resolution for private endpoints, but custom DNS configurations can also be set. End-to-End Security: Since the connection is over a private IP, it adds an additional layer of security by preventing any egress or ingress to public networks. Use Cases for Private Endpoints: Critical Security: Private endpoints are perfect for applications requiring high security, such as those handling sensitive data, financial transactions, or proprietary business logic. Strict Regulatory Compliance: If you are dealing with highly regulated industries (e.g., healthcare or finance), private endpoints provide a way to ensure your data is not exposed to the public internet. Network Isolation: Private endpoints are suited for scenarios where you want to fully isolate your Azure resources from the internet and only allow access from within your VNet. Key Differences: Private Endpoint vs. Service Endpoint Feature Private Endpoint Service Endpoint Connection Type Uses a private IP address from your VNet Uses a public IP address but routed through Azure's backbone network Security Level Higher security, no exposure to the public internet Lower security as it still uses public DNS and IP DNS Resolution Requires DNS configuration to resolve private IPs Relies on public DNS for resolution Use Case Ideal for critical security and isolated traffic Best for connecting to Azure services with basic security requirements Supported Services Limited to resources that support private endpoints Supports a broader range of Azure services like Storage, SQL, etc. When to Use Each Option Choose Service Endpoints if: You want to connect to Azure services like Storage, SQL, or Key Vault using the Azure backbone network. Your security requirements do not mandate complete isolation from the public internet. You need to leverage Network Security Groups (NSGs) to limit access from specific subnets or VNets. Choose Private Endpoints if: Your application requires full isolation from the public internet, such as for sensitive workloads or highly regulated data. You want traffic to flow entirely within the private network, ensuring complete confidentiality. You need to maintain strict security standards for applications that interact with services like databases, storage accounts, or other critical infrastructure. Conclusion Both Private Endpoints and Service Endpoints play vital roles in securing connectivity to Azure services, but they cater to different security needs. Service Endpoints offer an easier, simpler way to secure access over the Azure backbone, while Private Endpoints provide complete isolation and enhanced security by assigning a private IP address. By carefully assessing your application's security needs and performance requirements, you can choose the appropriate method to ensure optimal connectivity and compliance with Azure services.Azure VPN Gateway vs. ExpressRoute - Quick comparison
TL;DR. VPN Gateway provides secured connectivity between on-premises networks or clients to Azure services inside virtual networks. The data is encrypted through a private IPsec tunnel over the public internet. The configuration is easy. Price is a combination between he chosen VPN Gateway SKU and the outbound data transfer. It's usually used for small to medium scale production workloads for cloud services and virtual machines. ExpressRoute lets you extend your on-premises networks into the Microsoft clouds (Microsoft Azure and Microsoft 365) over a private dedicated connection with the help of a connectivity provider. The data is not encrypted, but does not go over the public Internet. Configuration is more complicated and involves the third party provider as well. The price is significantly higher than the VPN Gateway, and it is a combination of the Gateway type and the outbound data transfer. It's mostly used if really needed, for enterprise-class and mission critical workloads, Backup, Big Data, Azure as a DR site etc.End-to-end TLS with AKS, Azure Front Door, Azure Private Link Service, and NGINX Ingress Controller
This article shows how Azure Front Door Premium can be set to use a Private Link Service to expose an AKS-hosted workload via NGINX Ingress Controller configured to use a private IP address on the internal load balancer.
