Accessing Key Vault from Another Subscription Over Public Endpoint

[AndrewCoughlin]

Introduction

Hello everyone, it has been a while, 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 a key vault from a different subscription and from a different region in 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.

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 public endpoints, however private endpoints would require some additional work.  Are you looking for how to do this with private 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

• Tutorial: Use a managed identity to access Azure Key Vault - Windows - Azure AD - Microsoft Entra | ...
• 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

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.

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 and from a different region in a different subscription.  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.