We use Azure Container Apps (ACA) with Azure Files mounts to serve Neo4j graph databases. The ACA ARM API requires a storage account key to register file share mounts — there is no managed identity or Entra ID alternative. This blocks us from setting `all

Background We use Azure Container Apps (ACA) with Azure Files mounts to serve Neo4j graph databases. The ACA ARM API requires a storage account key to register file share mounts — there is no managed identity or Entra ID alternative. This blocks us from setting allowSharedKeyAccess: false on our storage account, which is required by an S360 compliance item.

Specific API Gap The CLI command: az containerapp env storage set \     --name <aca-env> \     --resource-group <rg> \     --storage-name <mount-name> \     --azure-file-account-name <account> \     --azure-file-account-key <key>         ← no MI alternative     --azure-file-share-name <share> \     --access-mode ReadWrite

The underlying ARM API Microsoft.App/managedEnvironments/storages (AzureFileProperties) requires accountKey as a string parameter. Verified through API versions up to 2026-01-01 — no identity or resourceId field exists.

At runtime, ACA also uses the cached key to authenticate SMB mounts when containers start. If allowSharedKeyAccess: false, mounts fail and containers can't access data.

ADO work item applied to ACI (should apply also for ACA): https://msazure.visualstudio.com/One/_workitems/edit/28139157

We have the following questions:

• Will it be managed identity support for Azure Files mounts on the ACA roadmap? if so, which API or timeline will it be delivered.
• Is there any alternative auth mechanism that works with managedEnvironments/storages today?