Announcing Virtual Network Service Endpoints for Key Vault (preview)
[Update: August 31, 2018 - This feature is now generally available. Refer to documentation for most up-to-date details. This post is maintained here for posterity.]
[This blog is co-authored with Sumeet Mittal, Program Manager, Azure Networking]
Hello again!
We are excited to announce the public preview of a long requested feature for Key Vault.
So you are using Key Vault to store encryption keys, application secrets, certificates and you worry about the Key Vault service endpoint being accessible from public internet. There are a few scenarios here:
- You want to lock down access to your key vault so that only your application or a short list of designated hosts can connect to your key vault
- You have an application running in your Azure virtual network (VNET) and this VNET is completely locked down for all inbound and outbound traffic. Your application still needs to connect to key vault to either fetch secrets or certificates or use cryptographic keys.
- You are using a key vault to store encryption keys used by Storage or Data Lake Store for service side encryption and you want to lock down access to this key vault from public internet.
If any of these scenarios applies to you, we have a new solution in preview. Please go ahead and give it a try and give us feedback.
As usual, we value your input so please take a moment to send us private feedback and/or visit our forum.
Quick overview:
So here's a quick summary of how it works.
The Virtual Network Service Endpoints for Key Vault allow customers to restrict access to key vault to specified Virtual Network and/or a list of IPv4 (Internet Protocol version 4) address ranges. Any caller connecting to that key vault from outside those sources will be denied access to this key vault. If customer has opted-in to allow "Trusted Microsoft services" such as Office 365 Exchange Online, Office 365 SharePoint Online, Azure compute, Azure Resource Manager, Azure Backup etc., connections from those services will be let through the firewall. Of course such callers still need to present a valid AAD token and must have the permissions to perform the requested operation. Read more technical details about Virtual Network Service Endpoints.
Note: Key Vault firewalls and virtual network rules ONLY apply to key vault data plane (read more about control plane and data plane). Key Vault control plane operations (such as key vault create, delete, modify operations, setting access policies, setting firewalls and virtual network rules) are not affected by firewalls and virtual network rules.
Note: This feature is still in preview. It is strongly recommended to not use this feature for any production scenarios. APIs, command line tools, Azure Portal user interface may change as we incorporate customer feedback, fix bugs and make improvements.
So follow along to get started quickly.
Setting up firewalls and virtual network rules:
Here's quick overview of steps required to set firewalls and virtual network rules. These steps remain same irrespective of what interface you'll use to setup the firewalls and virtual network rules.
- Optional but highly recommended: Enable key vault logging to see detailed access logs. This will help you in diagnostics when firewalls and virtual network rules prevent access to a key vault.
- Enable 'service endpoints for key vault' for target virtual network(s) and subnet(s)
- Set firewalls and virtual network rules for a key vault to restrict access to that key vault from specific virtual network(s), subnet(s) and IPv4 address ranges.
- A maximum 127 VNET rules and 127 IPv4 rules are allowed.
Using Azure Portal
- Visit Azure Portal
- Use existing key vault or create new key vault as necessary.
- Visit the key vault blade for which you want to set firewalls and virtual network rules.
- Azure Portal dashboard -> All Services -> click on 'Key vaults' under 'Security' section (you need to scroll down) -> Click on the key vault name.
- Click on 'Firewalls and virtual networks'. Note: You'll only see this item listed if you use the above Azure Portal URI.
- Click on 'Selected networks' under 'Allow access from:'
- To add existing virtual networks to firewalls and virtual network rules, click '+ Add existing virtual networks'.
- In the new blade that pops up, select the subscription, virtual network(s), and subnet(s) that you want to allow access to this key vault. If the virtual network(s) and subnet(s) you select do not have service endpoints enabled you'll a message as shown below. Click 'Enable' after confirming that you want to enable service endpoints for the listed the virtual network(s) and subnet(s). It may take up to 15 minutes to take effect.
- You can also add new virtual network(s) and subnet(s) and then enable service endpoints for the newly created virtual network(s) and subnet(s), by clicking '+ Add new virtual network' and following prompts.
- Under 'IP Networks' you can add IPv4 address ranges by typing IPv4 address ranges in CIDR (Classless Inter-domain Routing) notation or individual IP addresses.
Note: Small address ranges using "/31" or "/32" prefix sizes are not supported. These ranges should be configured using individual IP address rules.
IP network rules are only allowed for public IP addresses. IP address ranges reserved for private networks (as defined in RFC 1918) are not allowed in IP rules. Private networks include addresses that start with *10.**, *172.16.**, and *192.168.**. Note: Only IPv4 addresses are supported at this time.
If this key vault needs to be accessible by any trusted Microsoft services, click 'Yes' in the 'Exception' section. Following trusted Microsoft services are covered with this option.
Using Azure CLI 2.0
- Install Azure CLI 2.0 and Login.
- Install keyvault-preview extension. You must install the keyvault-preview extension to use the VNET Service Endpoints for Key Vault.
az extension add --name keyvault-preview
- List available virtual network rules, if you have not set any rules for this key vault, the list will be empty.
az keyvault network-rule list --resource-group myresourcegroup --name mykeyvault
- Enable Service Endpoint for Key Vault on an existing Virtual Network and subnet
az network vnet subnet update --resource-group "myresourcegroup" --vnet-name "myvnet" --name "mysubnet" --service-endpoints "Microsoft.KeyVault"
- Add a network rule for a virtual network and subnet
subnetid=$(az network vnet subnet show --resource-group "myresourcegroup" --vnet-name "myvnet" --name "mysubnet" --query id --output tsv) az keyvault network-rule add --resource-group "demo9311" --name "demo9311premium" --subnet $subnetid
- Add IP address range to allow traffic from
az keyvault network-rule add --resource-group "myresourcegroup" --name "mykeyvault" --ip-address "191.10.18.0/24"
- If this key vault needs to be accessible by any trusted services, set 'bypass' to AzureServices
az keyvault update --resource-group "myresourcegroup" --name "mykeyvault" --bypass AzureServices
- Now the final and important step, turn the network rules ON by setting the default action to 'Deny'
az keyvault update --resource-group "myresourcegroup" --name "mekeyvault" --default-action Deny
Using Azure PowerShell
- Install the latest Azure PowerShell and Login.
- Install preview version of AzureRM.KeyVault module
- List available virtual network rules, if you have not set any rules for this key vault, the list will be empty.
(Get-AzureRmKeyVault -VaultName "mykeyvault").NetworkAcls
- Enable Service Endpoint for Key Vault on an existing Virtual Network and subnet
Get-AzureRmVirtualNetwork -ResourceGroupName "myresourcegroup" -Name "myvnet" | Set-AzureRmVirtualNetworkSubnetConfig -Name "mysubnet" -AddressPrefix "10.1.1.0/24" -ServiceEndpoint "Microsoft.KeyVault" | Set-AzureRmVirtualNetwork
- Add a network rule for a virtual network and subnet
$subnet = Get-AzureRmVirtualNetwork -ResourceGroupName "myresourcegroup" -Name "myvnet" | Get-AzureRmVirtualNetworkSubnetConfig -Name "mysubnet" Add-AzureRmKeyVaultNetworkRule -VaultName "mykeyvault" -VirtualNetworkResourceId $subnet.Id
- Add IP address range to allow traffic from
Add-AzureRmKeyVaultNetworkRule -VaultName "mykeyvault" -IpAddressRange "16.17.18.0/24"
- If this key vault needs to be accessible by any trusted services, set 'bypass' to AzureServices
Update-AzureRmKeyVaultNetworkRuleSet -VaultName "mykeyvault" -Bypass AzureServices
- Now the final and important step, turn the network rules ON by setting the default action to 'Deny'
Update-AzureRmKeyVaultNetworkRuleSet -VaultName "mykeyvault" -DefaultAction Deny
Here is a list of trusted services that are allowed to access a key vault if the 'Allow trusted services' is checked, or equivalent '-bypass' option is used via CLI or PowerShell.
| Trusted services | Usage scenarios |
| Azure Virtual Machines deployment service | Deploy Certificates to VMs from customer-managed Key Vault |
| Azure Resource Manager (ARM) template deployment service | Pass secure values during deployment |
| Azure Disk Encryption volume encryption service | Allow access to BitLocker Key (Windows VM) or DM Passphrase (Linux VM) and Key Encryption Key during VM deployment to enable Azure Disk Encryption |
| Azure Backup | Allow backup and restore of relevant keys and secrets during Azure VM backup, using Azure Backup |
| Exchange Online & SharePoint Online | Allow access to customer key for Service Encryption with Customer Key. |
| Azure Information Protection | Allow access to tenant key for Azure Information Protection. |
| App Services (coming soon) | Deploying Azure Web App Certificate through Key Vault |
Note: The relevant key vault access policies must be set to allow the corresponding services to get access to key vault.
IMPORTANT: Once firewall rules are in effect, all Key Vault data plane operations can ONLY be performed when caller requests originate from allowed virtual network(s) or IPV4 address ranges. This also applies to accessing key vault from Azure portal. While a user can browser to a key vault from Azure portal, they may not be able to list keys/secrets/certificates if their client machine is not in the allowed list. This also affects the 'Key Vault Picker' by other Azure services. Users may be able to see list of key vaults but not list keys, if firewall rules prevent their client machine.
Known issues and limitations:
- Managed Service Identity (MSI) enabled Azure services that use Key Vault in the context of service side encryption at rest with customer managed key do not work when firewall rules are in effect. E.g. Azure Storage encryption with customer managed key, Azure Data Lake Store encryption with customer managed key, Azure SQL TDE with bring your own key. This limitation will be removed in a future release.
- For App Services only ASE (App Service Environment) instances are supported. This limitation will be addressed in a future release.
That's all folks!
We are eager to hear from you about virtual network service endpoints for Key Vault. So please reach out to us and let us know what you think.
Comments are disabled, head over to the Azure Key Vault forum to discuss about this blog.
References and links: