Azure Container Apps: managed-identity Azure Files mount gets GetKerbTicket 403 with storage firewall Deny

Question

Azure Container Apps: managed-identity Azure Files mount gets GetKerbTicket 403 with storage firewall Deny

Ryan Curtis 0

I’m testing Azure Container Apps in West US 2 with an Azure Files SMB share in East US.

Configuration:

VNet-integrated workload profiles environment using Consumption.
Environment system-assigned managed identity.
Storage File Data SMB MI Admin assigned at storage-account scope.
SMB OAuth enabled.
Storage firewall default Deny.
Environment subnet allowed through Microsoft.Storage.Global.

The mount fails before container startup. StorageFileLogs shows HTTPS GetKerbTicket requests using OAuth, returning 403 AuthorizationFailure. The requester object ID matches the environment identity.

Temporarily allowing only the observed caller IP makes the mount succeed. All 30 test files passed checksum verification. Removing that exception restores the restricted configuration.

What is the supported, durable network configuration for the GetKerbTicket request? Does this authentication traffic use a platform-managed network path outside the environment subnet? Would a storage private endpoint cover that path?

I want to retain managed-identity authentication and restricted storage access without maintaining an undocumented outbound IP allowlist.

0 comments

1 answer

Your answer

Answer 1

Hello Ryan Curtis

Your testing provides strong evidence that the failure is caused by the Azure Storage network restrictions rather than managed-identity permissions. The fact that allowing the observed caller IP makes GetKerbTicket succeed, while removing it restores the 403, is particularly useful.

Microsoft.Storage.Global is the correct service endpoint for cross-region access (West US 2 → East US).

However, service endpoints authorize traffic originating from the permitted VNet subnet. They do not automatically authorize requests originating from other Azure-managed infrastructure.

Since GetKerbTicket is an HTTPS authentication request occurring before container startup, a platform-managed network path outside your delegated subnet is a plausible explanation.

You can compare failed and successful requests using:

StorageFileLogs
| where OperationName == "GetKerbTicket"
| project TimeGenerated, StatusCode,
          StatusText, CallerIpAddress,
          RequesterObjectId, RequesterAppId,
          UserAgentHeader, CorrelationId
| order by TimeGenerated desc

Also confirm that the storage account contains an explicit virtual network rule for your environment subnet:

az storage account network-rule list \
  --account-name <storage-account> \
  --resource-group <resource-group> \
  -o json

Enabling the service endpoint alone is insufficient; the storage firewall must also allow the subnet.

A private endpoint is the preferred approach for private Azure Files connectivity, but it is not yet a confirmed solution for this specific authentication request.

You would need:

A storage private endpoint for the file subresource.
Private DNS zone privatelink.file.core.windows.net, linked to the appropriate VNet.
Confirmation that the component issuing GetKerbTicket actually uses that private endpoint.

If the authentication request originates outside the VNet and doesn't use its private DNS/routing path, adding a private endpoint alone may not resolve the 403.

Since Azure Files managed-identity mounts in Container Apps are currently a preview feature, I recommend opening an Azure Support case and requesting investigation by the Azure Container Apps and Azure Files engineering teams.

Provide the failed and successful GetKerbTicket correlation IDs, source IPs, UTC timestamps, and storage firewall configuration.

Ask Microsoft to confirm:

Whether GetKerbTicket originates from ACA-managed infrastructure outside the delegated subnet.
The officially supported firewall configuration for this authentication path.
Whether an Azure Files private endpoint covers both ticket acquisition and SMB traffic.

I would not recommend permanently allowlisting the observed public IP, since Microsoft does not document it as a stable or supported source for this operation.

Microsoft documentation: