Configuring Key Vault Network Settings

Complete the full lesson to earn 25 points — 50 with Pro

Work through each section, then tap “Mark as Complete” on the last one.

Section 1 of 12

✦ Skip the page breaks, the wait, and see fewer ads — read each lesson on a single page with Pro

Configuring Key Vault Network Settings: A Comprehensive Guide

Introduction: Why Network Security Matters for Azure Key Vault

In modern cloud environments, Azure Key Vault serves as the central nervous system for your secrets, encryption keys, and certificates. Because it holds the "keys to the kingdom," it is a primary target for attackers. If an adversary gains unauthorized access to your Key Vault, they could potentially decrypt sensitive data, impersonate services, or gain persistent access to your infrastructure. While identity-based access control (RBAC and Access Policies) is critical, it is only one layer of your security posture. Network security acts as the essential second layer, ensuring that even if credentials are compromised, the vault remains unreachable from unauthorized network locations.

Configuring network settings for Azure Key Vault involves defining exactly who can communicate with the vault and under what conditions. By default, a new Azure Key Vault is accessible from any network via its public endpoint. While this provides convenience, it is rarely appropriate for production workloads. In this lesson, we will explore how to restrict this access using virtual networks, IP address filtering, and private endpoints. We will also look at how Microsoft Defender for Cloud and Microsoft Sentinel help us monitor and enforce these configurations, ensuring that your security posture remains compliant over time.

Understanding the Network Architecture of Azure Key Vault

To effectively secure your Key Vault, you must first understand the three distinct network access modes available. Each mode offers a different balance between accessibility and security. Understanding these options is the foundation of cloud governance and compliance.

1. Public Access (All Networks)

This is the default configuration. When a Key Vault is created, it is assigned a public DNS name and a public IP address. It is reachable from any machine on the internet, provided the caller has the correct authentication tokens. While this is useful for testing or development, it creates a large attack surface. In a production environment, this should almost never be the standard unless your architecture specifically requires global, internet-based access for distributed services.

2. Public Access (Selected Networks)

This configuration keeps the public endpoint active but restricts access to specific IP ranges or specific Azure Virtual Networks. By using IP firewalls, you can limit access to your corporate office or on-premises data centers. By integrating with Virtual Networks (VNet) via service endpoints, you can ensure that only traffic originating from specific subnets within your Azure infrastructure can reach the vault. This is a common pattern for hybrid cloud setups.

3. Private Access (Private Link)

Private Link is the gold standard for network security in Azure. It removes the public endpoint entirely and replaces it with a private IP address within your own Virtual Network. The Key Vault is effectively "injected" into your VNet. Traffic never traverses the public internet; it stays within the Microsoft backbone network. This is the recommended approach for any mission-critical application handling sensitive keys.

Callout: The Difference Between Service Endpoints and Private Endpoints While both options secure your traffic, they work differently. Service Endpoints extend your VNet’s identity to the Azure service, allowing the service to recognize traffic as "internal." However, the service still exists on a public IP address. Private Endpoints, by contrast, assign a private IP address from your VNet directly to the service, completely removing the public endpoint from the equation. For high-security environments, Private Endpoints are preferred because they eliminate public exposure entirely.

Implementing Network Restrictions: Step-by-Step

Configuring these settings requires a methodical approach. You should always test network changes in a non-production environment before applying them to production, as an incorrect firewall rule could lock out your applications and cause an immediate service outage.

Step 1: Evaluating Current Network Configuration

Before changing any settings, you need to know what is currently allowed. You can check this via the Azure portal under the "Networking" tab of your Key Vault resource. Look for the "Allow access from" section. If it is set to "All networks," your vault is currently exposed to the public internet.

Step 2: Configuring IP Firewall Rules

If you need to permit traffic from an on-premises location, you must add the public IP address of that location to the firewall whitelist.

Navigate to your Key Vault in the Azure Portal.
Select Networking from the left-hand menu.
Choose Public endpoint (selected networks).
Under the Firewall section, input the CIDR range of your office or data center in the Address ranges box.
Click Save.

Warning: Lockdown Risk When you switch from "All networks" to "Selected networks," the firewall is enforced immediately. If you do not include the IP addresses of your own machine or your CI/CD pipelines in the whitelist, you will lose access to the vault immediately. Always ensure your current IP is added before saving the changes.

Step 3: Integrating with Virtual Networks

To allow resources within Azure to communicate with the Key Vault without leaving the Microsoft network, use Virtual Network integration.

Ensure that the Microsoft.KeyVault service endpoint is enabled on the subnet of your VNet.
In the Key Vault Networking tab, scroll to the Virtual networks section.
Click Add existing virtual network.
Select your VNet and the specific subnet.
Click Add and then Save.

Step 4: Deploying Private Link

For the highest level of security, implement Private Link.

In the Key Vault Networking tab, select the Private endpoint connections tab.
Click + Private endpoint.
Provide a name and choose the region.
Select the Resource (your Key Vault).
Choose the Virtual Network and Subnet where the private IP should reside.
Select Integrate with private DNS zone to ensure that your applications can resolve the vault's DNS name to the new private IP address automatically.

Automating Governance with Azure Policy

Manually configuring network settings for every Key Vault is prone to human error. In a large enterprise, you might have hundreds of vaults. To maintain a consistent security posture, you must use Azure Policy to enforce these network configurations automatically.

Azure Policy allows you to define rules that audit or deny the creation of Key Vaults that do not meet your network security standards. For instance, you can create a policy that denies the creation of any Key Vault that allows "All networks" access.

Sample Policy Definition (JSON)

The following code snippet is a simplified version of an Azure Policy definition that audits Key Vaults that have public network access enabled.

{
  "properties": {
    "displayName": "Audit Key Vault public network access",
    "policyType": "BuiltIn",
    "mode": "Indexed",
    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.KeyVault/vaults"
          },
          {
            "field": "Microsoft.KeyVault/vaults/publicNetworkAccess",
            "equals": "Enabled"
          }
        ]
      },
      "then": {
        "effect": "audit"
      }
    }
  }
}

By applying this policy at the subscription or management group level, you ensure that any developer attempting to create an insecure Key Vault will be flagged. You can change the effect from audit to deny if you want to strictly enforce the rule and prevent the creation of such resources entirely.

Integrating with Microsoft Sentinel

While Defender for Cloud focuses on posture and configuration, Microsoft Sentinel acts as your Security Information and Event Management (SIEM) system. It collects logs from your Key Vault and looks for malicious activity.

Setting Up Key Vault Logging

To use Sentinel effectively, you must first enable diagnostic logging for your Key Vault.

In the Key Vault, select Diagnostic settings.
Click Add diagnostic setting.
Select AuditEvent and AzurePolicyEvaluationDetails.
Send these logs to a Log Analytics Workspace.

Once the logs are flowing, you can write KQL (Kusto Query Language) queries in Sentinel to detect suspicious network-related activity, such as repeated access attempts from unauthorized IP addresses or failed attempts to modify the firewall settings.

Example KQL Query for Suspicious Activity

This query looks for any unauthorized access attempts (HTTP 403 Forbidden) that might indicate an attacker probing your firewall.

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where ResultSignature == "Forbidden"
| summarize count() by CallerIpAddress, bin(TimeGenerated, 1h)
| where count_ > 10

By setting up an alert on this query, you can be notified immediately if someone is attempting to brute-force or probe your Key Vault, allowing your security team to respond proactively.

Best Practices for Key Vault Network Security

Securing Key Vault is not just about flipping a switch; it is about following a set of established industry standards. Below are the core best practices for maintaining a secure vault configuration.

Principle of Least Privilege: Only allow the specific IP addresses or subnets that absolutely require access. Never use broad CIDR ranges unless strictly necessary.
Disable Public Access Entirely: Wherever possible, use Private Link. Removing the public endpoint eliminates an entire class of network-based attacks.
Use Infrastructure as Code (IaC): Manage your Key Vault configurations using Terraform, Bicep, or ARM templates. This ensures that network settings are version-controlled and deployed consistently, reducing the risk of manual configuration errors.
Centralize Logging: Ensure all Key Vault logs are sent to a central Log Analytics Workspace that is monitored by your security operations center (SOC).
Regular Audits: Use the Azure Resource Graph to periodically run queries to list all Key Vaults and their current network settings. This helps identify "shadow IT" or forgotten resources.

Comparison of Security Controls

Feature	Public Access	Public (Filtered)	Private Link
Public Endpoint	Yes	Yes	No
Network Isolation	None	Partial (IP/VNet)	Full (Private IP)
Complexity	Low	Medium	High
Security Level	Low	Medium	High

Common Pitfalls and How to Avoid Them

Pitfall 1: The "Break-Glass" Scenario

A common mistake is locking down the network so tightly that the Azure Portal itself cannot access the vault. Because the Azure Portal runs on the public internet, if you set the firewall to "Selected Networks" and do not include the Azure service tags or the specific IP ranges used by the portal, you will be unable to manage the vault via the web interface.

Solution: Always include the "AzureCloud" service tag in your firewall rules if you intend to manage the vault via the Portal. Alternatively, use PowerShell or Azure CLI from a machine that is already within the allowed network.

Pitfall 2: Forgetting CI/CD Pipelines

Developers often secure the Key Vault for the application runtime but forget that their CI/CD pipelines (like GitHub Actions or Azure DevOps) also need access to the vault to deploy secrets. When the network is locked down, the deployment pipeline fails.

Solution: Identify the IP addresses or the VNet integration points for your build agents. Ensure these are explicitly whitelisted in the Key Vault firewall settings.

Pitfall 3: Assuming "Private" Means "Secure"

Some believe that because they use a Private Endpoint, they don't need to worry about Identity and Access Management (IAM). This is a dangerous assumption. A Private Endpoint only secures the transport of data; it does not authorize the user.

Solution: Always combine network security with strict RBAC. Ensure that only the minimal set of users and service principals have the "Key Vault Secrets User" or "Key Vault Administrator" roles.

Pitfall 4: Misconfigured Private DNS Zones

When using Private Link, you must correctly configure the Private DNS zone. If the application cannot resolve the Key Vault's DNS name to the private IP address, it will attempt to reach the public endpoint, which will be blocked by the firewall.

Solution: Use the "Integrate with private DNS zone" option in the Azure Portal when creating the Private Endpoint. This automates the record creation and prevents DNS resolution issues.

Implementation Example: Terraform Configuration

Using Infrastructure as Code (IaC) is the best way to ensure your network settings are consistent. Below is a snippet of how you would define a Key Vault with a Private Endpoint using Terraform.

resource "azurerm_key_vault" "example" {
  name                        = "example-kv"
  location                    = var.location
  resource_group_name         = var.rg_name
  sku_name                    = "standard"
  tenant_id                   = var.tenant_id

  network_acls {
    default_action = "Deny"
    bypass         = "AzureServices"
  }
}

resource "azurerm_private_endpoint" "example" {
  name                = "example-pe"
  location            = var.location
  resource_group_name = var.rg_name
  subnet_id           = var.subnet_id

  private_service_connection {
    name                           = "example-psc"
    private_connection_resource_id = azurerm_key_vault.example.id
    is_manual_connection           = false
    subresource_names              = ["vault"]
  }
}

In this example, the network_acls block sets the default_action to Deny. This effectively closes the public door. The azurerm_private_endpoint resource then creates the private "tunnel" into the VNet. This is the most professional and secure way to manage Key Vault network settings.