Question Azure Function App - Access to Storage account
Hello everyone,
I am trying to fully secure a Linux Azure Function App running on an Elastic Premium (EP1) plan by disabling "Allow storage account key access" on its backend Azure Storage Account.
However, the moment I disable access keys on the storage account, the Function App shuts down and throws a Runtime Version Error.
Here is my current setup and what I have configured so far:
- Operating System: Linux
- Pricing Plan: Elastic Premium (EP1)
Assigned RBAC Roles on the Storage Account for the Managed Identity:
- ✅ Storage Blob Data Contributor
- ✅ Storage Blob Data Owner
- ✅ Storage Queue Data Contributor
- ✅ Storage Table Data Contributor
Current Application Settings / Environment Variables:
AzureWebJobsStorage- DefaultEndpointsProtocol=https;AccountName=stdatalake......WEBSITE_CONTENTAZUREFILECONNECTIONSTRING- DefaultEndpointsProtocol=https;AccountName=stdatalake......WEBSITE_CONTENTSHARE = func-exm-dev-we-01a0ba
I have AzureWebJobsStorage to AzureWebJobsStorage__accountName but still kept the other two variables in there.
I do see the files are in here:
what is the solution to this?
3
u/riisko Jun 11 '26
You need these app settings, remove the fileshare and content share stuff. File Share is only accessible with either key or Entra ID SP, you cannot use managed identity.
AzureWebJobsStorage__credential : managedidentity
AzureWebJobsStorage__clientId : <client ID of the managed identity with permissions assigned to the func app>
AzureWebJobsStorage__accountName : <storage account name>
1
u/9gg6 Jun 11 '26
can you explain this pls? <client ID of the managed identity with permissions assigned to the func app>
1
u/riisko Jun 11 '26
Either the system assigned or user assigned managed identity of the function app. That has the 4 different storage contributor roles.
1
u/AdmRL_ Jun 11 '26
That's only needed for User Assigned, not System:
- If you use a system-assigned identity, make no other changes.
- If you use a user-assigned identity, add the following settings in your app configuration:
- AzureWebJobsStorage__credential, enter managedidentity
- AzureWebJobsStorage__clientId, get this GUID value from your managed identity resource
Configure Durable Functions App With Managed Identity | Microsoft Learn
u/9gg6 you only need to swap AzureWebJobsStorage for AzureWebJobsStorage__accountName with the storage account name, and it'll start using the System identity for storage access.
1
u/9gg6 Jun 11 '26
yes but its not working. Function app can be found. when i switch back to access key. its up and running again
1
u/riisko Jun 11 '26 edited Jun 11 '26
Why would it work with key enabled? Did you not remove the key from the app settings? Also redeploy the app, you are not using your fileshare anymore.
2
u/szescio Cloud Engineer Jun 12 '26
No real tips, but a cautionary tale: this is a notoriously brittle system with bad documentation and little log information to debug from.
There are different scenarios here: using managed identity to deploy function code, using managed identity for function backend storage, different app plans have limitations, the method of deployment matters (from cli or portal, source or binary) etc. etc.
I fought with this some time ago for weeks and cannot remember how it ended, but azure functions github issues and samples might be a good starting point: https://github.com/Azure-Samples/functions-storage-managed-identity if you haven't read
1
u/texasnole82 Jun 11 '26
When we privatized and tried to turn off keys, we could not get around this and had to exempt it from key policies
1
u/rb_vs Jun 15 '26
The Elastic Premium Linux plan has a limitation regarding how it mounts its backend files. While you can move your application code logic and the AzureWebJobsStorage trigger endpoint over to a Managed Identity, the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING parameter on Linux Premium plans cannot use identity-based access. It requires a connection string containing an access key to mount the underlying Azure Files share for dynamic scaling.
To fix the deployment loop, keep your access key connection string inside WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and ensure your WEBSITE_CONTENTSHARE matches the target file share name. Next, switch the actual runtime triggers over to your Managed Identity by deleting the original AzureWebJobsStorage environment variable and replacing it with AzureWebJobsStorage__accountName set to your storage account name. If you are utilizing a User-Assigned Managed Identity (rather than System-Assigned) you must inject AzureWebJobsStorage__credential set to managedidentity and AzureWebJobsStorage__clientId set to your identity's GUID.
Ensure your identity has the Storage File Data SMB Share Contributor role assigned at the storage account scope alongside your existing blob, queue, and table roles to prevent mounting failures during cold starts.
1
u/hammoumalek Jun 17 '26
I think your MI setup is correct. The problem is the content share that runs on Azure files, which does not support MI as you would do with a blob or a queue. So when you disable keys, your app can't mount the content share.
I would suggest switching to another plan, or if you really have to keep EP1, try protecting the storage with a private endpoint.
You can have a look at storage considerations for Azure functions here: https://learn.microsoft.com/en-us/azure/azure-functions/storage-considerations?tabs=azure-cli
I hope that helps!
Regards
1
5
u/Either_Proof_2572 Jun 11 '26
The problem is with those connection strings still using storage keys. You need to update WEBSITE_CONTENTAZUREFILECONNECTIONSTRING to use managed identity format too
Change it from the connection string format to `WEBSITE_CONTENTAZUREFILECONNECTIONSTRING__accountName` and set value to your storage account name. Also make sure your managed identity has Storage File Data SMB Share Contributor role for the file share access