Accessing Key Vault from Another Subscription Over Private Endpoint


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 .



Reference Articles

Networking Setup

To get things set up, you first need a virtual .  You will create a virtual in both subscription 1 and subscription 2.  For 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 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.


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


  1. 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.


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


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


  1. Click Managed Identities.
  2. Click Select members.
  3. Select Subscription, Managed Identity, select the managed identity.
  4. Click Select.
  5. Click Review + assign.


  1. 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.

  1. Next, we will connect to the 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 zones
  • Use 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 , click on the Virtual Machine you will connect to.


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


  1. 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.


  1. We need to authenticate as the managed identity, for that we will type the two following commands:
$Response = Invoke-RestMethod -Uri ‘' -Method GET -Headers @{Metadata=”true”}

$KeyVaultToken = $Response.access_token

  1. 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.


  1. To get a secret from the key vault we will type the following:
Invoke-RestMethod -Uri https:///secrets/?api-version=2016-10-01 -Method GET -Headers @{Authorization=”Bearer $KeyVaultToken”}



  1. If required, to get a key from the key vault we will type the following:
Invoke-RestMethod -Uri https:///keys/?api-version=2016-10-01 -Method GET -Headers @{Authorization=”Bearer $KeyVaultToken”}





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.


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.


This article was originally published by Microsoft's SQL Server Blog. You can find the original article here.