Our platform team is designing Azure Key Vault usage for several applications in the same ART. We are considering either a separate vault for each application or one shared vault per environment. A shared vault would be easier for the platform team to operate, and the development teams are not very familiar with Azure, but each team must be prevented from accessing another team's secrets.
Ideally, teams would have their own isolated area in a shared vault and be able to add and manage their own secrets without always involving the platform team. Is that practical with Azure Key Vault, or is a separate vault per application or team a better design?
We also want applications to retrieve secrets without storing another secret for authenticating to the vault. What is the recommended authentication approach?
4 Answers
A shared vault can technically work, but the permissions need to be extremely granular. Azure attribute-based access control for Key Vault may help restrict access to particular secrets, though availability and maturity should be checked before relying on it. Managing those rules, role assignments, and exceptions can create more administration than simply giving each team its own vault.
Use managed identities so the applications do not need a password or client secret to access Key Vault. A user-assigned managed identity per application is often convenient, although system-assigned identities can also work depending on the architecture. Grant the identity only the required Azure RBAC role, such as permission to read secrets, and prefer the current Azure RBAC model over the older access-policy model.
If the platform team owns the deployment, provide a reusable Bicep or Terraform module that creates a vault, configures networking and retention settings, assigns the application identity, and applies the required RBAC roles. Teams can then provision their own vault through the approved module and manage their own secrets, while the platform team maintains the guardrails. A separate shared vault can still be used for genuinely platform-wide secrets.
A separate vault per application or team, per environment, is usually the cleaner design. Key Vault instances themselves do not have a significant fixed cost; charges are generally based on operations. With infrastructure as code, creating multiple vaults is straightforward. This gives each team clearer ownership, reduces the blast radius of a compromise, and makes it easier to remove an application and all of its secrets together.
It also avoids one shared vault becoming a single point of failure or turning into a difficult-to-manage collection of unrelated secrets.
That makes sense. We were mainly considering a shared vault to reduce operational work, but the extra permission management could eliminate that benefit.