Accessing multiple keyvaults in a multi tenant application (AKS)

Question

Hi,

We are building a multitenant SaaS application. The application tier is shared by tenants and backing services are isolated. We need to connect with customer specific keyvault's to get credentials/secrets via application code when required. What is the best way to authenticate to keyvault in this scenario? The keyvault will be in different subscriptions.

The application runs in AKS. One option I was thinking is to use the client credentials and storing the creds per customer specific key vault in a shared vault (reference) and assign this vault to the pod (managed identity). Not sure if this is the right approach. Is there any better option to achieve this?

Answer 1

@Nikhil Digde

Thank you for your detailed post!

I'm not too familiar with AKS, but to hopefully help point you in the right direction from the Key Vault side of things, I'll share some potential solutions below. I'll also summarize your issue to ensure I fully understand what you're asking.

---

Environment:

1. You currently have a multi-tenant SaaS application which runs in AKS.

Issue:

1. You need to connect to your customers specific Key Vault's to get credentials (i.e. Secrets).
2. These Key Vaults will be in different subscriptions, and I'm assuming different tenants (per customer).
3. You'll need to connect to these vaults via application code, when required.

When it comes to the best way of authenticating to a customer's Key Vault in a multitenancy scenario, this'll depend on the Isolation model that works best for you and your customer. For more info.

From the option you shared, I believe you're closely modeling a Vault per tenant, in the tenant's subscription. This approach is appropriate when you allow customer-managed keys (CMKs) for encryption within your solution.

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, but it requires that you deploy and manage an increasing number of vaults, as you increase the number of tenants.

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... 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 potential security liability.

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.

Additional Links:

• Azure Kubernetes Service (AKS) considerations for multitenancy
• Multitenancy and Azure Key Vault
• Architectural approaches for identity in multitenant solutions
• Checklist for architecting and building multitenant solutions on Azure
• Use a managed identity in Azure Kubernetes Service (AKS)

I hope this helps!

If you have any other questions, please let me know. Thank you for your time and patience throughout this issue.

---

If the information helped address your question, please Accept the answer. This will help us and also improve searchability for others in the community who might be researching similar information.