Azure Files security compatability on Container Apps and Web App for Containers

3 minute read | By Anthony Salemo

This post will go over compatable security settings when using Azure Storage and Container Apps and Web Apps for Containers.

Overview

In terms of storage, Container Apps allows Azure Files to be mounted from an Azure Storage Account, as well as Web Apps for Containers - Mount Azure Storage as a local share in App Service. This post refers to the security settings that can be chosen on an Azure Files Share under Security -> Protocol settings.

Behavior

This will show up as volume mount failure with mount error(13): Permission denied

  • One thing to note with Web App for Containers is that logging may not be available whene a volume mount is failing. See What kind of issues will I see?
  • This does NOT apply to Azure Container Apps. You will be able to see volume mount failures in Diagnose and Solve Problem or by viewing system logs in the log destination you have set

Compatability

These are two different container services offered on Azure, but share the same concept surrounding mounting volumes and what security side settings are set on an Azure File share when mounting volumes.

Azure Files security tab

When creating a Storage Account through typical means (eg. portal, or others - with default settings), the Security -> Protocol Settings default to Maximum Compatibility - which is the below, where all options are checked. This means any that fail will fallback to others that may work:

Azure Files security protocol settings

If a configuration is chosen that is not one that is applicable with ACA, this will manifest as Storage Volume errors on the Container App side with mount error(13): Permission denied. You can find more information on troubleshooting mount issues here. The Permission denied error will show in your Container App’s system logs.

Aside from using Maximum Capability (which just checks every box), the “highest” realistic settings a user can do when setting Profile -> Custom is the following:

  • SMB protocol versions: SMB 3.1.1, SMB channel encryption: AES-128-GCM, (Optional: Authentication mechanisms -> NTLM V2)

Explicitly using only Kerboros authentication will fail. This cannot be used. Additionally, using SMB 3.1.1 with only AES-256-GCM will also fail. Using any lower versions of SMB under 3.1.1 will fail.

Using the Maximum Security profile will also fail, since this uses the following - SMB 3.1.1, AES-256-GCM, Kerberos (with Kerberos ticket encryption -> AES-256)

In short, sticking with Maximum Capatability or setting a custom profile to SMB protocol versions: SMB 3.1.1, SMB channel encryption: AES-128-GCM, (Optional: Authentication mechanisms -> NTLM V2) are the two general options that can be done.

For other storage troubleshooting articles, see: Container Apps:

Web Apps for Containers:

You may also enjoy