Container App unable to fetch Key Vault-referenced secret via Managed Identity

Question

Summary

We cannot provision a revision for an Azure Container App because it fails to

fetch a Key Vault-referenced secret via its user-assigned managed identity

(UAMI), despite the identity having a confirmed, correct, and long-standing

"Key Vault Secrets User" RBAC role assignment on the target vault. The error

is fully reproducible and has persisted across many hours and multiple

distinct code paths.

Error message (verbatim, reproduced identically across all attempts)


Failed to provision revision for container app ''.

Error details: The following field(s) are either invalid or missing.

Field 'configuration.secrets' is invalid with details:

'Invalid value: "": Unable to get value using

Managed identity /subscriptions//resourceGroups//providers/Microsoft.ManagedIdentity/userAssignedIdentities/

for secret .

Error: unable to fetch secret '' using

Managed identity '/subscriptions//.../userAssignedIdentities/'';.'

What we've ruled out (with evidence)

RBAC / permissions — The identity has the "Key Vault Secrets User" role assigned directly on the Key Vault scope. Confirmed present via az role assignment list. Most recently, we destroyed and recreated this exact role assignment fresh, waited ~6 minutes (1m14s creation + 300s explicit propagation delay) before the container app apply, and the identical error still occurred — ruling out RBAC propagation delay as the cause.
Key Vault network/firewall — Vault uses private endpoint + private DNS; NSGs/route tables checked and correct; DNS resolution from the container apps environment subnet confirmed correct.
Resource ID casing — Confirmed the identity resource ID casing matches exactly between the UAMI resource and its reference in the container app's identity block and configuration.secrets entry.
Stale/corrupted resource state — Fully destroyed and recreated the Container App resource itself (not just updated) via a targeted Terraform -replace; the brand-new resource creation failed with the identical error, ruling out corrupted Terraform/ARM resource-instance state.
Client/API path (Terraform vs Azure Portal vs Azure CLI) — Reproduced the identical error via three independent client paths: (a) Terraform's azapi_resource full-resource PUT, (b) the Azure Portal's own native "Add secret" dialog (Key Vault Reference type, same identity), and (c) the dedicated `az containerapp secret set --secrets "name=keyvaultref:...,identityref:..."` CLI command, which uses a narrower, secrets-specific update endpoint distinct from a full resource PUT (this was suggested as a working two-pass workaround in community reports on GitHub issue microsoft/azure-container-apps#1174, but did not work for us). All three independent client code paths fail with the byte-for-byte identical error message, ruling out any PUT-vs-PATCH, Terraform/azapi-provider-specific, or client-tooling theory — the Container Apps control plane itself fails this validation for this identity/vault/secret combination regardless of which client or API surface is used to request it.
Secret history — The secret was never deleted/recreated in this vault (no soft-delete/purge-protection conflict).
Vault access mode / trusted services — Vault uses RBAC authorization mode (not legacy access policies); Microsoft.App is confirmed not on Key Vault's "trusted Microsoft services" bypass list, so that bypass is not relevant here (network path is already private-endpoint based).

Suspected root cause

This matches publicly reported Azure Container Apps platform issues:

microsoft/azure-container-apps#722 (2023) — Microsoft confirmed an identical error was caused by a platform release regression and fixed it server-side with no customer-side action required.
microsoft/azure-container-apps#1174 (open) — same error text; community reports describe it as a non-deterministic/stochastic failure in the platform's secret-fetch validation, occasionally resolved by retrying with no configuration changes. A recent comment on this thread describes it as a race where RP-side validation runs during the PUT against an identity binding that isn't yet observable internally, distinct from Key Vault RBAC propagation.
microsoft/azure-container-apps#1804 (open) — a near-identical sibling container app succeeds while another with the same configuration pattern fails, suggesting an identity- or resource-instance-specific fault on the Azure side rather than a customer configuration issue.

Question

Has anyone found a working resolution or official Microsoft-confirmed root

cause for this? We suspect a platform-side bug similar to the previously

fixed #722, since RBAC is confirmed correct and has had ample time (6+

minutes) to propagate, and the failure reproduces identically across

Terraform, the Azure Portal, and the Azure CLI. This is blocking the

first-ever deployment of a new service into this Container Apps

environment.

Answer

Hello @Pas, Mike

Based on the troubleshooting you've already completed, I agree that this no longer looks like a normal Key Vault RBAC, Terraform, or client-side configuration issue.

Microsoft's documented requirements for a Key Vault reference in Azure Container Apps are essentially:

The managed identity must be assigned to the Container App.
That identity must have permission to read the secret; with Key Vault RBAC, Microsoft recommends the Key Vault Secrets User role.
The Key Vault secret URI and identity reference must be valid.
Network connectivity to Key Vault must be available.

You've already validated those points and, more importantly, reproduced the same control-plane error through Terraform, Azure Portal, and az containerapp secret set. That makes a Terraform/AzAPI implementation problem unlikely.

One thing to verify before escalating is the deployment dependency/order around the Key Vault private endpoint and private DNS configuration. Explicitly making the Container App depend on the private endpoint resolved that deployment.

If the private endpoint/DNS resources already exist independently and this still fails hours later, however, deployment ordering wouldn't explain the persistent failure.

At that point, treat this as a likely Azure Container Apps resource-provider/control-plane issue and open an Azure support case. Include:

Container App resource ID and Container Apps Environment resource ID.
UAMI resource ID and principalId.
Key Vault resource ID and secret URI (without exposing the secret value).
The Key Vault Secrets User role assignment details.
Exact timestamps and correlation/activity IDs from failed deployments.
Confirmation that the same operation fails through Portal, CLI, and ARM/AzAPI.
Confirmation that private DNS resolves the vault through its private endpoint from the Container Apps environment.

Don't keep recreating the RBAC assignment. Since the same assignment existed long-term before being recreated and the failure persists across independent API paths, repeatedly changing RBAC is unlikely to provide useful additional evidence.

As a diagnostic test, if your security requirements permit it temporarily, you could create a separate test Key Vault without private-endpoint restrictions, grant the same UAMI Key Vault Secrets User, and reference a disposable test secret. If that works, you've isolated the problem to the private networking/control-plane path. If it produces the identical failure, that gives Microsoft stronger evidence of an ACA identity/secret-reference validation problem.

Microsoft's current Container Apps documentation also has a dedicated troubleshooting section for Key Vault references covering managed identity, identity assignment, disabled secrets, authentication, and RBAC failures. Your testing appears to have already gone beyond those documented customer-side causes.

So I think your suspicion is reasonable: if the private endpoint is fully established and DNS/connectivity are confirmed, this warrants Microsoft investigation rather than more Terraform or RBAC changes.

Sharing these references with you:

Manage secrets in Azure Container Apps

Azure CLI – az containerapp secret

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.