Azure Key Vault data-plane RBAC does not recognize valid role assignment for App Service managed identity in Azure Managed Application managed resource group

Bruno Costa 0 Reputation points

We have an Azure Marketplace Managed Application deployed into a customer subscription. One of the deployed App Services uses a system-assigned managed identity to resolve App Service Key Vault references from an Azure Key Vault in the same managed resource group.

The App Service Key Vault references are failing with:

Status: AccessToKeyVaultDenied Details: Key Vault reference was not able to be resolved because site was denied access to Key Vault reference's vault.

The Key Vault is configured with Azure RBAC authorization enabled:

{
 "enableRbacAuthorization": true,
 "publicNetworkAccess": "Enabled"
}

The App Service managed identity has the Key Vault Secrets User and Key Vault Secrets Officer roles assignments at the Key Vault scope.

Despite this, Key Vault audit logs show the SecretGet request from the same managed identity is denied because no assignment is found:

`OperationName: SecretGet ResultSignature: Forbidden httpStatusCode_d: 403 isRbacAuthorized_b: false

ResultDescription: Caller is not authorized to perform action on resource. If role assignments, deny assignments or role definitions were changed recently, please observe propagation time.

Action: Microsoft.KeyVault/vaults/secrets/getSecret/action

Assignment: (not found) DenyAssignmentId: null DecisionReason: null `

Troubleshooting already performed:

  1. Confirmed the App Service Key Vault reference uses SystemAssigned identity.
  2. Confirmed the managed identity object ID in the Key Vault audit log matches the current App Service system-assigned identity.
  3. Confirmed Key Vault Secrets User exists at the Key Vault scope for that exact principal.
  4. Added Key Vault Secrets Officer at the Key Vault scope for the same principal as an additional test.
  5. Refreshed App Service Key Vault references using: az rest --method post \ --url "https://management.azure.com${APP_ID}/config/configreferences/appsettings/refresh?api-version=2022-03-01"
  6. Updated App Service app settings to trigger refresh.
  7. Restarted the App Service.
  8. Removed and recreated the App Service system-assigned managed identity, which generated a new principal ID.
  9. Recreated the Key Vault RBAC assignments for the new managed identity.
  10. Confirmed Key Vault audit logs now show the new managed identity, but the same RBAC failure remains.
  11. Confirmed the Key Vault request reaches Key Vault, so this does not appear to be a networking or private endpoint issue.
  12. Confirmed the Key Vault audit log shows DenyAssignmentId: null.

Managed Application deny assignment context:

The managed resource group has a system deny assignment created by the Managed Application:

Deny assignment: bb27aa59-83d0-47af-ad83-c558aceb30ea Scope: /subscriptions/xxxxxxxxxxxxxxxxxxxxx/resourceGroups/mrg-name

Condition:

@Subject[ResourceId] StringNotStartsWithIgnoreCase '/subscriptions/xxxxxxxxxxxxxxxxxxxxx/resourceGroups/mrg-name' && @Subject[tid] StringNotEqualsAnyOfIgnoreCase {'xxxxxxxxxxxxxxxxxxxxxxxx'}

The caller resource ID from the Key Vault log is:

/subscriptions/xxxxxxxxxxxxxxxxxxxxxxxx/resourcegroups/mrg-name/providers/Microsoft.Web/sites/app-name

This appears to start with the managed resource group path, so the first part of the deny assignment condition should evaluate to false. Therefore the deny assignment should not apply to this App Service managed identity. The Key Vault audit log also reports:

DenyAssignmentId: null

The deny assignment has:

"dataActions": ["*"],
"notDataActions": [
 "*/read",
 "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action",
 "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read",
 "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write",
 "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete"
]

However, because the caller is a resource inside the managed resource group, our understanding is that the deny assignment condition should exempt this caller.

We would like to understand why Key Vault data-plane RBAC is not recognizing the valid role assignment for this App Service managed identity in the context of an Azure Managed Application managed resource group.

  1. VEMULA SRISAI 13,415 Reputation points • Microsoft External Staff • Moderator

    Hello Bruno Costa,

    Thank you for the detailed troubleshooting information.

    Based on the investigation shared, the Key Vault RBAC configuration itself appears correct. The App Service system-assigned managed identity has valid Key Vault data-plane roles assigned, and the Key Vault audit logs confirm that the requests are reaching the vault successfully.

    However, the authorization evaluation is still returning:

    • isRbacAuthorized_b: false

    Assignment: (not found) httpStatusCode_d: 403

    Since this environment is deployed through an Azure Managed Application, one important factor is the deny assignment automatically applied to the managed resource group. Even though the audit logs show DenyAssignmentId: null, Managed Application deny assignments can still affect effective data-plane authorization behavior for managed identities in certain scenarios.

    In particular, Key Vault data-plane authorization is evaluated against the managed identity principal itself, rather than only the ARM resource path of the App Service resource. Because of this, there may be an interaction between the Managed Application isolation model and Key Vault RBAC evaluation for managed identities inside the managed resource group.

    At this stage, the recommended validation/workaround steps are:

    Test using a Key Vault deployed outside the Managed Application managed resource group. Test with a user-assigned managed identity configured through keyVaultReferenceIdentity. Verify whether the same behavior occurs when the Managed Application is deployed without restrictive deny-assignment settings (if applicable). Allow sufficient RBAC propagation time after identity recreation and role reassignment.

    If the issue persists even after moving the Key Vault outside the managed resource group, please let us know.

  2. VEMULA SRISAI 13,415 Reputation points • Microsoft External Staff • Moderator

    Bruno Costa I’m following up on my previous response to check whether it was helpful. Please feel free to reach out if you need any further assistance—I’ll be happy to help.

  3. Bruno Costa 0 Reputation points

    Hi Vemula,

    Thanks for the explanation. I understand the recommendation to place the Key Vault outside the managed resource group, but I’d like to challenge/clarify the product expectation here.

    For a publisher-managed Azure Managed Application, the managed resource group is intended to work as a protected “black box” controlled by the publisher. In that model, it seems reasonable that resources deployed inside the same managed resource group should be able to securely communicate with each other, especially for a standard pattern like:

    App Service managed identity → Key Vault secret reference

    Is this an intended platform limitation or a bug/gap in Key Vault data-plane RBAC evaluation for Azure Managed Applications?

    In our latest test, we updated the Marketplace plan’s Allowed data actions and confirmed the generated deny assignment now includes:

    Microsoft.KeyVault/vaults/secrets/getSecret/action Microsoft.KeyVault/vaults/secrets/readMetadata/action Microsoft.KeyVault/vaults/secrets/*

    If the intended design is that internal resources in a deny-protected managed resource group cannot use Key Vault data-plane access even when the relevant data actions are explicitly allowed, that has a significant impact on Marketplace solution architecture. It would mean a standard internal dependency such as App Service → Key Vault cannot be fully contained inside the managed resource group.

    Is there any supported way to keep the Key Vault inside the managed resource group while allowing only the managed application’s own identities to read secrets, without exposing management control to the customer?

  4. VEMULA SRISAI 13,415 Reputation points • Microsoft External Staff • Moderator

    Bruno Costa Thanks for the clarification. Based on current platform behavior, this is not an expected or supported scenario.

    In Azure Managed Applications, the deny assignment applied to the managed resource group can impact Key Vault RBAC data‑plane authorization, even for managed identities belonging to resources inside the same managed resource group. Key Vault evaluates data‑plane access purely on the effective RBAC authorization of the calling principal, and in this context the deny assignment prevents RBAC from resolving the role assignment, resulting in the 403 error you are seeing.

    As of today, App Service → Key Vault using RBAC is not supported when both resources are inside a deny‑protected managed resource group, even if the required Key Vault data actions are explicitly allowed.

  5. VEMULA SRISAI 13,415 Reputation points • Microsoft External Staff • Moderator

    Bruno Costa could you please let me know if you need any further assistance or additional information on this.

Sign in to comment
Sign in to answer

Your answer