Azure Key Vaults should use private link

What does the recommendation "Azure Key Vaults should use private link" check?

Flags any key vault that has no approved private endpoint connection, so its secrets, keys and certificates are still reachable over the public service endpoint rather than only across a private link inside your virtual network. It checks for the presence of an approved private endpoint, not whether you have also locked the public side down: a vault with 'publicNetworkAccess' set to Disabled but no private endpoint still flags, and so does one reachable purely through firewall IP rules. It says nothing about who can read those secrets once connected, which is governed separately by RBAC or access policies, nor about whether the data they hold is sensitive. The control is about the network path only.

Why does "Azure Key Vaults should use private link" matter?

Key Vault is where the rest of your estate keeps its database passwords, API keys and TLS certificates, so it is a single high-value target. With a public endpoint, that vault is reachable from anywhere on the internet and the only thing standing between an attacker and your secrets is data-plane authentication and any firewall rules you remembered to set. A leaked credential, a token replayed from outside, or a permissive IP allowlist then exposes every secret at once, and a single compromised vault can unlock databases, sign tokens and decrypt storage across the whole subscription. A private endpoint pins data-plane traffic to a private IP inside your VNet, so the vault simply cannot be reached from the public internet even if a credential leaks. That reduces the blast radius of a stolen secret from your entire estate to whatever already sits inside the network.

How do I fix "Azure Key Vaults should use private link"?

1. Create a private endpoint for the vault in the subnet that hosts its consumers, then approve the connection: 'az keyvault private-endpoint-connection approve'. This is the step the control actually grades.
2. Add the privatelink.vaultcore.azure.net Private DNS zone and link it to your VNet so clients resolve the vault name to its private IP rather than the public one, otherwise traffic still tries the public path.
3. Once private connectivity is confirmed working, close the public side with 'az keyvault update --public-network-access Disabled'. Decide first whether any trusted Azure services need the 'Allow trusted Microsoft services' bypass, since Disabled blocks everything except private endpoint and trusted-service traffic.

# Put a production vault behind a private endpoint, then close its public door.
VAULT=kv-payments-prod
RG=rg-payments
SUBNET=/subscriptions/<sub>/resourceGroups/rg-net/providers/Microsoft.Network/virtualNetworks/vnet-prod/subnets/snet-data

# 1. Create the private endpoint (group-id 'vault') in the workload subnet.
az network private-endpoint create \
  --name pe-$VAULT --resource-group $RG \
  --vnet-name vnet-prod --subnet snet-data \
  --private-connection-resource-id $(az keyvault show -n $VAULT --query id -o tsv) \
  --group-id vault --connection-name conn-$VAULT

# 2. Link the private DNS zone so the vault name resolves to the private IP.
#    (privatelink.vaultcore.azure.net linked to vnet-prod, A record from the PE)

# 3. Once a dependent service can still read a secret over the PE, close the door.
az keyvault update --name $VAULT --resource-group $RG \
  --default-action Deny --bypass AzureServices \
  --public-network-access Disabled
echo "$VAULT: private endpoint live, firewall Deny, public network access disabled"

# Ratchet it shut: audit every vault for private link across the subscription.
az policy assignment create \
  --name audit-kv-private-link \
  --policy a6abeaec-4d90-4a02-805f-6b26c4d3fbe9 \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"