Multitenancy and Azure Key Vault
Azure Key Vault is used to manage secure data for your solution, including secrets, encryption keys, and certificates. In this article, we describe some of the features of Azure Key Vault that are useful for multitenant solutions. We then provide links to the guidance that can help you, when you're planning how you're going to use Key Vault.
Isolation models
When working with a multitenant system using Key Vault, you need to make a decision about the level of isolation that you want to use. The choice of isolation models you use depends on the following factors:
- How many tenants do you plan to have?
- Do you share your application tier between multiple tenants, do you deploy single-tenant application instances, or do you deploy separate deployment stamps for each tenant?
- Do your tenants need to manage their own encryption keys?
- Do your tenants have compliance requirements that require their secrets are stored separately from other tenants' secrets?
The following table summarizes the differences between the main tenancy models for Key Vault:
| Consideration | Vault per tenant, in the provider's subscription | Vault per tenant, in the tenant's subscription | Shared vault |
|---|---|---|---|
| Data isolation | High | Very high | Low |
| Performance isolation | Medium. High throughput might be limited, even with many vaults | High | Low |
| Deployment complexity | Low-medium, depending on the number of tenants | High. The tenant must correctly grant access to the provider | Low |
| Operational complexity | High | Low for the provider, higher for the tenant | Lowest |
| Example scenario | Individual application instances per tenant | Customer-managed encryption keys | Large multitenant solution with a shared application tier |
Vault per tenant, in the provider's subscription
You might consider deploying a vault for each of your tenants within your (the service provider's) Azure subscription. This approach provides you with strong data isolation between each tenant's data. However, it requires that you deploy and manage an increasing number of vaults, as you increase the number of tenants.
There's no limit to the number of vaults you can deploy into an Azure subscription. However, you should consider the following limits:
- There are subscription-wide limits on the number of requests you can make within a time period. These limits apply regardless of the number of vaults in the subscription. So, it's important to follow our throttling guidance, even when you have tenant-specific vaults.
- There's a limit to the number of Azure role assignments that you can create within a subscription. When you deploy and configure large numbers of vaults in a subscription, you might approach these limits.
Vault per tenant, in the tenant's subscription
In some situations, your tenants might create vaults in their own Azure subscriptions, and they might want to grant your application access to work with secrets, certificates, or keys. This approach is appropriate when you allow customer-managed keys (CMKs) for encryption within your solution.
In order to access the data in your tenant's vault, the tenant must provide your application with access to their vault. This process requires that your application authenticates through their Microsoft Entra instance. One approach is to publish a multitenant Microsoft Entra application. Your tenants must perform a one-time consent process. They first register the multitenant Microsoft Entra application in their own Microsoft Entra tenant. Then, they grant your multitenant Microsoft Entra application the appropriate level of access to their vault. They also need to provide you with the full resource ID of the vault that they've created. Then, your application code can use a service principal that's associated with the multitenant Microsoft Entra application in your own Microsoft Entra ID, to access each tenant's vault.
Alternatively, you might ask each tenant to create a service principal for your service to use, and to provide you with its credentials. However, this approach requires that you securely store and manage credentials for each tenant, which is a security liability.
If your tenants configure network access controls on their vaults, make sure you're able to access the vaults. Design your application to handle situations where a tenant changes their network access controls and prevents you from accessing their vaults.
Shared vaults
You might choose to share tenants' secrets within a single vault. The vault is deployed in your (the solution provider's) Azure subscription, and you're responsible for managing it. This approach is simplest, but it provides the least data isolation and performance isolation.
You might also choose to deploy multiple shared vaults. For example, if you follow the Deployment Stamps pattern, it's likely you'll deploy a shared vault within each stamp. Similarly, if you deploy a multi-region solution, you should deploy vaults into each region for the following reasons:
- To avoid cross-region traffic latency when working with the data in your vault.
- To support data residency requirements.
- To enable the use of regional vaults within other services that require same-region deployments.
When you work with a shared vault, it's important to consider the number of operations you perform against the vault. Operations include reading secrets and performing encryption or decryption operations. Key Vault imposes limits on the number of requests that can be made against a single vault, and across all of the vaults within an Azure subscription. Ensure that you follow the throttling guidance. It's important to follow the recommended practices, including securely caching the secrets that you retrieve and using envelope encryption to avoid sending every encryption operation to Key Vault. When you follow these best practices, you can run high-scale solutions against a single vault.
If you need to store tenant-specific secrets, keys, or certificates, consider using a naming convention like a naming prefix. For example, you might prepend the tenant ID to the name of each secret. Then, your application code can easily load the value of a specific secret for a specific tenant.
Features of Azure Key Vault that support multitenancy
Tags
Key Vault supports tagging secrets, certificates, and keys with custom metadata, so you can use a tag to track the tenant ID for each tenant-specific secret. However, Key Vault doesn't support querying by tags, so this feature is best suited for management purposes, rather than for use within your application logic.
More information:
Azure Policy support
If you decide to deploy a large number of vaults, it's important to ensure that they follow a consistent standard for network access configuration, logging, and access control. Consider using Azure Policy to verify the vaults have been configured according to your requirements.
More information:
Managed HSM and Dedicated HSM
If you need to perform a large number of operations per second, and the Key Vault operation limits are insufficient, consider using either Managed HSM or Dedicated HSM. Both products provide you with a reserved amount of capacity, but they're usually more costly than Key Vault. Additionally, be aware of the limits on the number of instances of these services that you can deploy into each region.
More information:
- How do I decide whether to use Azure Key Vault or Azure Dedicated HSM?
- Is Azure Dedicated HSM right for you?
Contributors
This article is maintained by Microsoft. It was originally written by the following contributors.
Principal author:
- John Downs | Principal Software Engineer
Other contributors:
- Jack Lichwa | Principal Product Manager, Azure Key Vault
- Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure
To see non-public LinkedIn profiles, sign in to LinkedIn.
Next steps
Review deployment and configuration approaches for multitenancy.