How to Give an Azure Managed Identity Access to Key Vault Secrets with RBAC

Azure Key Vault separates management operations from access to keys, secrets, and certificates. For application access, Microsoft recommends Azure role-based access control (RBAC), managed identities, and least-privilege role assignments rather than embedding credentials in application settings. [1]

This guide shows a common pattern: give an Azure-hosted application’s managed identity permission to read Key Vault secrets without giving it broad administrative access.

Choose the smallest suitable role

• Key Vault Secrets User: read secret contents. This is normally the right choice for an application that only needs to retrieve secrets at runtime.
• Key Vault Secrets Officer: perform secret operations, except managing permissions. Use this only when a trusted automation process must create, update, or delete secrets.
• Key Vault Reader: read vault and object metadata, but not secret values.
• Key Vault Administrator: full data-plane access to keys, secrets, and certificates. Reserve this for tightly controlled administration.

Microsoft’s RBAC guidance warns that the Key Vault Contributor role manages the vault resource but does not grant access to secret values. It also warns that excessive control-plane permissions can allow a user to grant themselves data-plane access, so keep Contributor and role-assignment permissions tightly controlled. [2]

1. Prepare the Key Vault

1. Open the target Key Vault in the Azure portal.
2. Check the vault’s permission model. For this guide, use Azure role-based access control.
3. Confirm that the application and vault belong to the same intended environment, such as development, pre-production, or production.
4. Make sure the person assigning access has permission to create Azure role assignments, such as an appropriate User Access Administrator, Owner, or constrained Key Vault Data Access Administrator role.

Microsoft recommends using a vault per application and environment. This limits the blast radius if one application or environment is compromised. [2]

2. Find the application’s managed identity

Identify the managed identity used by the application or service. This may be a system-assigned identity attached directly to an Azure resource or a user-assigned identity shared by selected resources. Record the identity’s name so you do not accidentally grant access to a similarly named user, group, or application registration.

3. Assign Key Vault Secrets User in the portal

1. In the Key Vault, open Access control (IAM).
2. Select Add, then Add role assignment.
3. Choose the Key Vault Secrets User role.
4. Keep the scope as narrow as the application design allows. A vault-level assignment is the normal starting point for a dedicated application vault.
5. For the member type, select Managed identity.
6. Select the application’s managed identity, review the assignment, and complete it.

Do not select Key Vault Administrator simply because it is easier. A read-only application should receive a read-only data-plane role. If the application must write or rotate secrets, use a separate deployment or automation identity with the minimum role required.

4. Test the application path

Restart or redeploy the application if its identity token is cached, then test the normal code path that reads the secret. Confirm that the application can read the intended secret and cannot read an unrelated vault if your design uses separate vaults. Also test a denied operation, such as attempting to manage role assignments, to confirm that the identity does not have administrative privileges.

5. Harden the vault after access works

• Use separate vaults for development, pre-production, and production where the environments have different trust boundaries.
• Prefer managed identities so the application does not store a client secret or certificate for its own Azure authentication.
• Apply network restrictions that fit the workload. Microsoft lists private endpoints as the most restricted option and also documents firewall and network-perimeter approaches.
• Enable soft delete and purge protection, and plan secret rotation before production rollout.
• Review role assignments regularly and use just-in-time privileged access for administrators where practical.

Common mistakes

• Assigning Key Vault Reader: metadata access is not the same as permission to read secret values.
• Using Key Vault Contributor for an application: this is a management-plane role, not the correct secret-reading role.
• Mixing access policies and RBAC during migration: Microsoft warns that changing the permission model can invalidate existing access-policy permissions and cause outages if equivalent roles are not assigned first.
• Putting every application in one vault: shared boundaries increase the impact of a compromise.

Sources

1. Microsoft Learn: Secure your Azure Key Vault
2. Microsoft Learn: Azure RBAC for Key Vault data plane operations