Accessing Key Vault from Another Subscription Over Private Endpoint

Introduction

Hello everyone, Andrew Coughlin here and I am a Cloud Solutions Architect at Microsoft focusing on Azure IaaS.  I recently received questions from a few of my customers about access to a key vault from a different subscription.  In this blog I will walk through the process of using a managed identity and access an Azure Key Vault from another subscription with private endpoint.

 

Environment Setup

Let’s first discuss the setup of what we will be discussing in this blog post.  I will have two subscriptions assigned to the same Azure AD Tenant.   Within each Azure subscription I will have a resource group in each.  I will create the Azure Key Vault in one subscription / resource group and then I will create a virtual machine in the other subscription / resource group.  This is just for example purposes; I could utilize other azure services that can use managed identities.   I could also create a service principal for my application to use to get keys or secrets.

In this example we would be using private endpoints.  Are you looking for how to do this with public endpoints?  Check out my recent post on how to do that here .

 

 

Prerequisites

• Requires Powershell 7.x: Migrating from Windows PowerShell 5.1 to PowerShell 7 - PowerShell | Microsoft Docs.
• Create Virtual Machine as outlined in Quickstart - Create a Windows VM in the Azure portal - Azure Virtual Machines | Microsoft Docs, no need to install IIS.
• Create Azure Key Vault as outlined in Quickstart - Create an Azure Key Vault with the Azure portal | Microsoft Docs, standard key vault will work in this example.
• Create a Secret in the Key Vault as outlined in this step: Azure Quickstart - Set and retrieve a secret from Key Vault using Azure portal | Microsoft Docs.
• Create a Key in the Key Vault as outlined in this step: Azure Quickstart - Set and retrieve a key from Key Vault using Azure portal | Microsoft Docs.

 

Reference Articles

• Create Tutorial: Use a managed identity to access Azure Key Vault - Windows - Azure AD - Microsoft Entra | Microsoft Docs
• Best practices for using Azure Key Vault | Microsoft Docs
• Managed identities for Azure resources - Microsoft Entra | Microsoft Docs
• Use Azure service principals with Azure PowerShell | Microsoft Docs
• What is a private endpoint? | Microsoft Docs

 

Networking Setup

To get things set up, you first need a virtual network.  You will create a virtual network in both subscription 1 and subscription 2.  For step-by-step instructions on how to perform this head over to the QuickStart guide for creating virtual networks.  Both networks should not be overlapping, as you are not able to peer overlapping virtual networks.

Once both virtual networks are configured, our next step is to configure the vnet peering between both virtual networks you just created.  For step-by-step instructions on how to create vnet peering head over to the Create, change, or delete a virtual network peering guide.

 

Setup Azure Virtual Machine

1. Login to the Azure Portal.
2. Next, I will click on the virtual machine that I will be using in this demonstration.

3. Scroll down the identity and ensure that the System assigned identity is On.

 

4. Next, we will move onto configuring the Key Vault.

 

Setup Azure Key Vault

1. In the Azure Portal navigate to Key Vaults, click on the Key Vault you want to configure.

 

2. Click on Access control (IAM), Click Add, Click Add role assignment.

 

3. Type key vault and select the role you want to assign based on your requirements.

 

4. Click Managed Identities.
5. Click Select members.
6. Select Subscription, Managed Identity, select the managed identity.
7. Click Select.
8. Click Review + assign.

 

9. Click Review + assign.

 

NOTE: It may take a few minutes for permissions to fully populate, give it a few minutes (5-10 minutes) before proceeding to the next step.

 

10. Next, we will connect to the VM and retrieve a secret and/or keys.

 

Setup Azure Key Vault Private Endpoint

At this stage we have the virtual networks created and configured, the virtual machine setup with managed identity and just configured Azure Key vault with RBAC.  Next, we need to set up the private endpoint.  When we setup the key vault in the prerequisites it set the key vault connectivity method to allow public access.  Once we are done it will only be configured via private ip address. To complete this step, we will head over to the Integrate Key Vault with Azure Private Link page.

 

Setup DNS solution for Private Endpoint

There are a couple of ways you can configure DNS for your private endpoint deployment:

• Host Files (only recommended for testing)
• Use private DNS zones
• Use DNS Forwarder
• Use DNS private resolver (Preview)

To understand what will work best for your organization I recommend checking out the Azure private endpoint DNS configuration page or for non-production deployments take a look at the upcoming feature Azure DNS private resolver that is currently in preview at the time of this blog post.

In my example above, I have two DNS servers, one that is deployed within the same subnet as my private endpoint in subscription 1.  Then the other DNS server deployed in subscription 2, with forwarding to the DNS server in subscription 1.  In a production deployment you would want your DNS servers highly available. Once you have your DNS solution deployed you will want to make sure the vNET’s DNS server configuration is updated to point to the correct DNS solution.

 

Access Azure Key Vault

1. Navigate to Virtual Machines, click on the Virtual Machine you will connect to.

 

2. Click Connect and click Download RDP File, Login to the virtual machine.

 

3. Open PowerShell on the system you just RDP.

 NOTE: This requires PowerShell 7.x, if you try to run PowerShell 5.X this process will not work.

 

4. We need to authenticate as the managed identity, for that we will type the two following commands:

 

 

$Response = Invoke-RestMethod -Uri 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net' -Method GET -Headers @{Metadata="true"}

$KeyVaultToken = $Response.access_token

 

 

5. If you want to confirm there is a value in $KeyVaultToken, you can type $KeyVaultToken and press Enter to see the results.

NOTE: You should not share this token.

 

 

6. To get a secret from the key vault we will type the following:

 

 

Invoke-RestMethod -Uri https://<your-key-vault-URL>/secrets/<secret-name>?api-version=2016-10-01 -Method GET -Headers @{Authorization="Bearer $KeyVaultToken"}

 

 

NOTE: <your-key-vault-URL, will be the vault URI, secret-name will be the name you give for the secret.

 

7. If required, to get a key from the key vault we will type the following:

 

 

Invoke-RestMethod -Uri https://<your-key-vault-URL>/keys/<key-name>?api-version=2016-10-01 -Method GET -Headers @{Authorization="Bearer $KeyVaultToken"}

 

 

NOTE: <your-key-vault-URL, will be the vault URI, key-name will be the name you give for the key.

Conclusion

That is, it... In case you were wondering, "Would this work in a scenario that a virtual machine or service is in region A and the key vault is in region B with both resources in different subscriptions?", yes, this would work as well. In this blog I have covered how to access a key vault from a different subscription over private endpoints.  Thank you for taking the time to read this blog, I hope this helps you and see you next time.

 

Disclaimer

The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.