Azure Key Vault with Azure Service Endpoints and Private Link — Part 1
Azure Service Points (SE) and Azure Private Link (PL) are two pretty fundamental and essential services when we are talking about network security in Azure.
There are similarities and differences between these two services and sometimes, the behavior of these two are different on Azure service itself. So, as an solution architect, besides reading the office documents, the best way is to walk them through.
Therefore, I will do a series of SE and PL walk through on common Azure services such as SQL database, Redis cache, Key Vault, Storage account and MySQL.
The walk through procedure is simple and standard for all mentioned services. I will create SE and PL for each services, perform network connectivity from both EC2 and from Azure Vnet so to understand exactly how SE and PL works in action.
Below I list out some characteristics of SE and PL based on my understandings. For more detailed information, please refer to official document.
This is a long article, you can jump to the end just to find out the conclustion :D
Azure Virtual Network Service Endpoints
- Provides secure and direct connectivity to Azure services
- Over optimized route over Azure backbone network
- Allow you to secure Azure service only to your Subnet
- Enables communication to Azure service through private IP address
What is the cache?
- If you have site-to-site VPN from on-premise to Vnet, you CANNOT access Azure service through SE from on-premise
- Using SE DOES NOT mean Azure service becomes privately accessible ONLY. You can still allow internet access to Azure service by configuring it’s firewall
Image：Azure portal
Azure Private Link
- Enables you to access Azure services and Azure hosted customer-owned/partner services over private endpoint in your Vnet
- Traffic between Vnet and Azure services travels Microsoft backbone network through private IP
- PL will use private IP address from your Vnet and map it to Azure service
- Because of the above, If you have VPN peered to Vnet, you CAN access Azure services through PL
- When configuring PL, Azure private DNS zone service can be enabled to host PL DNS with Azure for connection query
- Once enabled, Azure service is NO LONGER accessible from internet
Without further ado, let’s get started with Azure Key Vault.
My Demo Structure
My structure is pretty simple, I have a Vnet with three subnets called serviceEndpoint, privateLink and default each with a VM in Azure and an AWS EC2. They will be used to perform connectivity test to Key Vault configured with SE and PL.
Configure Azure Service Endpoint for Azure Key Vault
Actually you can configure SE and PL during Key Vault (KV) setup process but for demo purpose, I configured allow all network to begin with.
To configure Azure KV SE, follow the steps below
- Follow №1 to №4 to add SE
- №5 & №6, select Vnet and the subnet for SE
- №7, SE needs to be enable on subnet, so enabled it first
Process of enabling SE.
Select the subnet for SE once SE is enabled from previous step.
Once added, DO NOT forget to save the configuration!
We can verify from subnet if SE is indeed enabled for cross checking.
Also, we can verify the Routes of VM location in SE integrated subnet.
Next we need to assign privilege to VM in serviceEndpoint and default subnet so it can access Azure key Vault. We do that by enabling VM’s System managed identity.
Now back to Azure Key Vault, we allow VM to access KV by assigning access policy to the identity just created.
When adding policy,
- №1, select the privilege would like to assign. Key, Secret and Certificate permission will auto bring out once №1 is picked.
- №3, Select the name of the VM
Repeat previous steps for VM in default subnet
Lastly, DO remember to Save the configuration.
Azure Service Endpoint Connectivity Test
First, let’s test if anything is changed from DNS perspective. Let’s dig from AWS EC2,
VM in default,
and serviceEndpoint subnet.
From the results above, we can conclude that configuring SE does not affect DNS query. Next, I want to test what’s the IP address I used to access KV, so I will enable access logging for KV.
Setup access logging as steps below, modify at your requirement.
Next, in order to access KV from Azure portal, for result verifying, we need to setup KV’s FW to allow our current location IP. Before setting it up, from Azure portal,
Add your current location IP to FW. /32 is not compulsory. DO remember to Save. Now, you can access the Keys, Secrets and Certificates page.
Now, let’s connect to KV using this python sample code from three different locations and see what will happen with current configuration.
For EC2, I use CLI credential, please refer here.
In short, there are different ways to authenticate with Azure, please refer here for more details.
Code used on EC2.
Result of running python code on EC2, we can see clearly that EC2 is trying to access KV from internet and is denied by KV’s firewall.
Access KV from Azure Default subnet, we could see that the result is same as accessing from EC2.
Lastly, lets access from serviceEndpoint integrated subnet and as expected, it succeed!!
We could verify it from Secrets section too.
Let’s allow EC2 and VM in default subnet to access KV by adding their IP on KV’s FW and test again.
Run the python code again and it succeed!
And verifying from Secrets section again, we do see all three values added!
How is Key Vault accessed by the VMs?
This is the important part of serviceEndpoint. From tests above, we could almost tell that EC2 and VM in default subnet is access KV through public IP. What about VM in SE subnet?
Use the code below to query Azure Key Vault logs. Let’s find out.
Before adding EC2 and VM in default to KV’s FW, the logs are as below. We can confirm that both VMs were trying to access KV from their public IP and denied by KV.
After IPs have been added to FW, from logs again, we can confirm that EC2 and VM in default subnet are now able to access KV from public IP address.
Whereas VM in subnet integrated with Service Endpoint, can access KV directly through its PRIVATE IP address without any problem and that’s exactly expected!!
Conclusion
Through this lab, some facts are confirmed.
- DNS query result IS NOT affected with Service Endpoint configured. Public IP address is responded to all VMs
- Having that ↑ said, VM in SE integrated subnet access KV through its PRIVATE IP address.
- With SE configured, sources outside the SE integrated subnet, CAN access to KV through internet, prior to having access policy and FW setup.
This article is getting longer than I expected. I will do KV with Azure Private Link in another article. Stay tuned!
