Key Vault Firewall and Private Endpoint

Azure Key Vault firewall is a network security feature that restricts access to your Key Vault based on the source IP address or virtual network origin of requests. By default, when you create a Key Vault, its firewall is disabled, meaning it is accessible from any public IP address over the internet as long as the request is properly authenticated and authorized. This is a significant security risk, especially for production environments. The firewall allows you to explicitly deny all traffic except from specified sources. There are three modes: - Allow all networks (default): No firewall, accessible from any IP. - Allow only selected networks: You specify allowed IP addresses (IPv4 CIDR) and/or virtual networks (via service endpoints or private endpoints). - Allow only private endpoints: All public access is blocked; only connections through private endpoints are allowed.

When a request reaches Azure Key Vault, the firewall evaluates the source IP of the request. If the firewall is set to 'Allow only selected networks', it checks whether the source IP matches any of the listed IP ranges or if the request originated from a virtual network with a service endpoint enabled for Microsoft.KeyVault. Service endpoints allow you to secure Azure service resources to your virtual network by extending your VNet identity to the service. The request must also be authenticated via Azure AD and authorized via Key Vault access policies or RBAC. If the source IP is not allowed, the request is denied with an HTTP 403 Forbidden response, even if the credentials are valid. This is a key point: the firewall operates at the network layer, before authentication. So, even a valid user with proper permissions cannot access the vault if their source IP is blocked.

Using Azure CLI:

# Create a Key Vault with firewall enabled (deny all)
az keyvault create --name MyVault --resource-group MyRG --default-action Deny

# Add an IP rule to allow a specific IP
az keyvault network-rule add --name MyVault --ip-address 203.0.113.0/24

# Add a virtual network rule (requires service endpoint)
az keyvault network-rule add --name MyVault --subnet mySubnet --vnet-name myVNet

# Update the default action to allow only selected networks
az keyvault update --name MyVault --default-action Deny

# Verify firewall rules
az keyvault show --name MyVault --query properties.networkAcls

Using PowerShell:

# Create a Key Vault with firewall enabled
New-AzKeyVault -VaultName MyVault -ResourceGroupName MyRG -DefaultAction Deny

# Add IP rule
Add-AzKeyVaultNetworkRule -VaultName MyVault -IpAddressRange 203.0.113.0/24

# Add virtual network rule
Add-AzKeyVaultNetworkRule -VaultName MyVault -VirtualNetworkResourceId /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Network/virtualNetworks/{vnet}/subnets/{subnet}

# Update default action
Update-AzKeyVault -VaultName MyVault -DefaultAction Deny

Azure Private Endpoint is a network interface that connects you privately and securely to Azure Key Vault via Azure Private Link. It uses a private IP address from your virtual network, effectively bringing the Key Vault into your VNet. Traffic between your virtual network and the Key Vault travels entirely over the Microsoft backbone network, never traversing the public internet. This eliminates exposure to the public internet and provides protection against data exfiltration.

When you create a private endpoint for Key Vault, a network interface (NIC) is created in your subnet with a private IP address. A DNS configuration is automatically updated so that the Key Vault's FQDN (e.g., myvault.vault.azure.net) resolves to the private IP address within your VNet. This DNS resolution happens via Azure Private DNS Zones. For on-premises environments, you can use custom DNS servers or Azure DNS Private Resolver. The private endpoint is associated with a Private Link service that Microsoft manages on the Key Vault side. All requests from your VNet to the Key Vault are routed through the private endpoint, and the Key Vault firewall sees the request as coming from the private endpoint's private IP, which is allowed if the firewall is configured to allow private endpoints only.

When you enable a private endpoint, you can set the Key Vault firewall to 'Allow only private endpoints'. This blocks all public traffic, including traffic from trusted Microsoft services, unless you explicitly allow them via a separate setting. However, note that some Azure services (like Azure App Service) may need to access Key Vault via a managed identity; in such cases, you may need to allow trusted services or use a service endpoint if private endpoint is not possible.

# List private endpoints for a Key Vault
az network private-endpoint list --resource-group MyRG --query "[?privateLinkServiceConnections[0].privateLinkServiceId.contains(@, 'MyVault')]"

# Check DNS resolution
nslookup myvault.vault.azure.net
# Should resolve to private IP if configured correctly

Key Vault firewall and private endpoint are complementary security controls. Firewall restricts access at the network layer based on source IP or VNet, while private endpoint provides a private, secure connection that bypasses the internet entirely. For the AZ-500 exam, you must understand how to configure both, their interactions, and common pitfalls.

A large bank runs a critical application on Azure VMs that needs to access encryption keys stored in Key Vault. The security team mandates that no traffic should traverse the public internet. They deploy a private endpoint for Key Vault in the same VNet as the application VMs. The Key Vault firewall is set to 'Allow only private endpoints'. The application uses managed identity to authenticate to Key Vault. This setup ensures that all key retrieval traffic stays within the Azure backbone and the bank's VNet. Performance is excellent because the private endpoint provides low latency (typically <1ms added). A common issue they encountered was that the application's DNS cache still pointed to the public IP initially; they had to flush DNS or configure the private DNS zone correctly. They also had to ensure that the subnet used for private endpoint had network policies disabled, otherwise the private endpoint creation would fail.

A SaaS company has a multi-tier application: a public-facing web app (Azure App Service) and a backend API on VMs. The web app needs to retrieve database credentials from Key Vault. They cannot use a private endpoint for the web app because it is publicly accessible, so they use a service endpoint. They enable Microsoft.KeyVault service endpoint on the subnet hosting the web app and add a virtual network rule in Key Vault. The Key Vault firewall is set to allow that VNet and also allows trusted Microsoft services (for Azure Resource Manager operations). However, they also have a separate Key Vault for development that is only accessed from the corporate network via a VPN. That Key Vault uses IP firewall rules to allow the corporate VPN IP range. This hybrid approach works well but requires careful management of IP changes. A common mistake was forgetting to update IP rules when the VPN gateway IP changed, causing dev access to break.

A healthcare company must ensure that all access to patient data encryption keys is restricted to a specific Azure region. They deploy Key Vault with private endpoint in the same region as their workloads. They also enable diagnostic settings to log all Key Vault requests. They use Azure Policy to enforce that all Key Vaults must have private endpoints and firewall set to deny public access. They also configure the private DNS zone to be linked to all VNets in the region. A performance consideration: when using private endpoint, the number of concurrent connections can be high, but Azure Private Link supports up to 10,000 flows per private endpoint. They monitored for any DNS resolution failures and found that sometimes the private IP was not resolving if the VNet was not linked to the private DNS zone. They resolved this by automating the DNS zone linkage using Azure Policy.