Question

Difficulty: MediumAzure Key Vault Secret, Key, and Certificate Management

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?

  1. Assign the Key Vault Secrets User role to the system-assigned managed identity of the App Service at the Key Vault scope.Answer
  2. B
    Add a Key Vault access policy that grants the Get permission for secrets to the system-assigned managed identity of the App Service.
  3. C
    Assign the Reader role to the system-assigned managed identity of the App Service at the Key Vault scope.
  4. D
    Configure 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

1
Identify the active authentication identity of the App Service.
The application uses its system-assigned managed identity to authenticate against Azure Active Directory (Microsoft Entra ID).
We must grant permissions to the exact identity that requests token generation for accessing the Key Vault.
2
Determine the required permission scope and role.
The application needs to read secret values. Under Azure RBAC, the built-in role that allows reading secrets is the Key Vault Secrets User role.
Adhering to the principle of least privilege means avoiding broader roles like Key Vault Administrator or Key Vault Secrets Officer.
3
Assign the role using the Azure portal, CLI, or PowerShell.
The Key Vault Secrets User role is assigned to the system-assigned managed identity at the Key Vault resource scope.
This links the managed identity to the data-plane permission required to perform Key Vault GET operations on secrets.

Key Concept

Azure Key Vault RBAC permission model and data-plane role assignment
Estimated Time:1m 30s
Rate this question