Azure Container Apps: listSecrets authorization fails for user with Owner via Entra ID group, despite RBAC appearing correct

Service

Azure Container Apps, Azure RBAC (role-based access control), Microsoft Entra ID group-based role assignments, Azure CLI (containerapp extension).

Scenario

I'm deploying via Azure CLI and calling az containerapp auth microsoft update against an existing Container App as part of a deploy script. This command requires the Microsoft.App/containerApps/listSecrets/action permission to read the app's microsoft-provider-authentication-secret.

For one specific user account, this single step fails — even though:

• Two prior az containerapp update calls against the same resource, in the same CLI session, under the same identity, succeed without error immediately before this step.
• The same deploy script, run by our CI pipeline under a dedicated service principal that has Container Apps Contributor granted directly at the container-app scope, succeeds every time.
• Running the same script on my machine with my az login succeeds against the same Azure resources.

The only difference I can identify is that the failing user's permissions come from Owner and Contributor roles assigned to a Microsoft Entra ID security group at the subscription scope, rather than a role assigned directly to a principal at the resource scope.

Result

ERROR: (AuthConfigListSecretsAuthorizationFailed) The client is not authorized to use secrets
from container app '<container-app-name>' in an auth configuration. The
'Microsoft.App/containerApps/listSecrets/action' permission is required.

Environment

• azure-cli: 2.81.0
• containerapp extension: 1.3.0b1
• authV2 extension: 1.0.1
• Resource type: Microsoft.App/containerApps
• Command: az containerapp auth microsoft update --name <app> --resource-group <rg> --client-id <id> --client-secret-name microsoft-provider-authentication-secret --tenant-id <tenant> --yes

Troubleshooting efforts

I verified the following via Azure CLI and Microsoft Graph, all of which point to RBAC being correctly configured:

1. az role assignment list --scope <container-app-resource-id> --include-inherited shows the affected user's Entra ID security group holds both Owner and Contributor at the subscription scope (assigned well over a year ago — not a new assignment).
2. Confirmed the group is a static, security-enabled group — not dynamic membership, not mail-enabled.
3. az ad group member check confirms the affected user is a direct member of that group.
4. az lock list at both the resource group and container-app scope returns empty — no ReadOnly/CanNotDelete locks in play.
5. Queried the denyAssignments API directly against the container-app resource — returns empty, so no deny assignment is blocking the action.

Given Owner's action set is ["*"] with no NotActions, I'd expect listSecrets to be included unconditionally via the group.

Reproducible steps

1. Create a Container App with the Microsoft auth (authV2) config disabled/pending.
2. Grant a Microsoft Entra ID security group Owner (or Contributor) at the subscription scope, and confirm a target user is a member.
3. As that user, run az containerapp update against the app — succeeds.
4. Immediately after, as the same user in the same session, run az containerapp auth microsoft update against the same app — fails with AuthConfigListSecretsAuthorizationFailed.
5. Compare against a principal with the equivalent role assigned directly (not via group) at the resource scope — step 4 succeeds for that principal.

Question

Is there a known difference in how the Container Apps listSecrets action (or the authV2/auth-config subsystem specifically) evaluates group-based role assignments versus directly-assigned roles, e.g., a separate authorization cache with a longer TTL, or a limitation on group nesting/resolution for this particular action? Any ideas on what the difference could be in these cases where the call succeeds vs fails that we could try?