Your organization is migrating the permission model of an Azure Key Vault named `kv-payment-prod` to use the Azure role-based access control permission model instead of Vault access policies. An Azure App Service web application named `app-payment-prod` uses a system-assigned managed identity to retrieve database connection secrets from this Key Vault. Immediately after you change the permission model to Azure RBAC, the web application fails to retrieve secrets, returning a `403 Forbidden` error. Which action should you perform to restore the application's access to the secrets while adhering to the principle of least privilege?
- Assign the Key Vault Secrets User role to the system-assigned managed identity of the App Service at the Key Vault scope.Answer
- BAdd a Key Vault access policy that grants the Get permission for secrets to the system-assigned managed identity of the App Service.
- CAssign the Reader role to the system-assigned managed identity of the App Service at the Key Vault scope.
- DConfigure the App Service to use a new user-assigned managed identity, but keep the Key Vault Secrets User role assigned only to the system-assigned managed identity.
Answer
Assign the Key Vault Secrets User role to the system-assigned managed identity of the App Service at the Key Vault scope.
Assigning the Key Vault Secrets User role to the system-assigned managed identity at the Key Vault scope is correct because the Key Vault has been transitioned to the Azure RBAC permission model, where access policies are ignored. The Key Vault Secrets User role grants the necessary data-plane permissions (GET and LIST) to retrieve secrets, following the principle of least privilege.
Step-by-Step Solution
Key Concept
Azure Key Vault RBAC permission model and data-plane role assignment
Estimated Time:1m 30s