Our platform team is designing secrets management for several applications in the same delivery group. We could manage one Key Vault per environment, or create separate vaults for each application or team. A shared vault would be easier for the platform team and simpler for development teams, but we must ensure that applications and teams cannot access one another's secrets. Ideally, teams could add and manage secrets in their own isolated area without having to ask the platform team every time. Is that isolation practical in a shared vault, or is a separate vault per application or team the better design? Also, what is the recommended way for applications to authenticate to Azure Key Vault without storing another secret for authentication?
4 Answers
Applications should not authenticate with a client secret just to read Key Vault. Use Microsoft Entra ID managed identities instead. A user-assigned managed identity per application is often convenient, especially when the identity needs to survive resource replacements, although system-assigned identities can also work. Grant the identity the minimum required Azure RBAC role, such as permission to read secrets, on the relevant vault or secrets. The application’s Azure SDK can then obtain tokens automatically through that managed identity.
Separate vaults per application or team per environment are usually the cleaner option. Key Vault instances themselves generally do not create a significant cost difference; charges are mainly based on operations. With infrastructure as code, creating a small vault module for each team is straightforward. This gives teams clearer ownership, makes removing an application and its secrets easier, and reduces the blast radius if one identity or vault is compromised. You can still maintain a separate shared vault for genuinely platform-wide secrets.
A shared vault can work, but it requires very careful authorization. Use Azure RBAC rather than the older Key Vault access policy model, and assign each application or team an identity with access only to the secrets it owns. Attribute-based access control for Key Vault may provide more granular secret-level restrictions where available, but check its support status and operational overhead before making it the foundation of your design. In practice, separate vaults are often simpler and safer than trying to create virtual folders inside one vault.
Before choosing a shared vault, consider whether someone could accidentally reuse another team’s secret, whether all secrets can be removed cleanly with an application, and whether temporary access can be granted to exactly one team without exposing everything else.
Let teams create and update their own secrets through infrastructure as code, such as Bicep or Terraform, rather than giving broad portal permissions or making every change a platform-team ticket. The platform team can provide a reusable module that creates the vault, diagnostic settings, RBAC assignments, private networking, and retention protections. This keeps the process self-service while preserving consistent security controls.
It also avoids turning one shared vault into a single point of failure or a large administrative bottleneck.