Azure Functions Flex Consumption — Security Isolation of Deployment Storage Write Permissions

Azure Functions Flex Consumption does not provide the requested security boundary: an identity attached to the Function App for deployment storage is available to application code, and the supported Flex deployment-storage configuration grants that identity write-capable Storage Blob Data Contributor access.

Flex Consumption security properties

1. Runtime code can obtain tokens for the deployment identity

A user-assigned managed identity must be attached to the Function App before Flex Consumption can use it for deployment storage. Managed identities attached to App Service or Azure Functions are intentionally available to application code through the managed-identity token endpoint or Azure Identity libraries; code can select a user-assigned identity explicitly.^1^

Therefore, attaching a user-assigned deployment identity does not create a deployment-service-only identity. Untrusted or compromised function code can request a Storage token for it.

2. The supported Flex role is write-capable

For either a user-assigned or system-assigned deployment-storage identity, the documented Flex configuration assigns Storage Blob Data Contributor scoped to the deployment storage account.^2^

That role permits reading, writing, adding, moving, and deleting blobs; it also includes container-level operations.^3^ Consequently, application code using that identity receives the same data-plane permissions.

Scope can be narrowed where the deployment configuration permits, but narrower scope does not separate callers using the same identity. It only limits which storage resources they can modify.

3. A read-only deployment identity is not documented for Flex

Storage Blob Data Reader provides read/list access only.^4^ However, the supported Flex deployment contract calls for Storage Blob Data Contributor, not Reader. The available documentation does not describe a Flex configuration in which:

• the Function App uses a read-only identity to load its package; and
• an independent deployment principal writes packages without giving the app’s identity write access.

Flex uses managed package deployment. Deployment clients submit the package to /api/publish; the deployment service processes it and stores it in the configured container. Directly uploading a ZIP to that container does not constitute a Flex deployment.^5^

The minimum documented and supported Flex data-plane assignment is therefore:

• Function App deployment identity: Storage Blob Data Contributor
• Scope documented by the Flex configuration guidance: deployment storage account

That arrangement does not meet the stated isolation requirement.

Package writes versus package-reference changes

These are separate authorization surfaces:

• Package modification: Blob Storage data-plane permissions. The deployment identity’s Storage Blob Data Contributor role permits package writes and deletes.
• Changing deployment configuration or package references: Azure Resource Manager control-plane permissions over the Function App. Managed-identity Blob RBAC does not itself grant permission to alter Function App settings.
• Runtime filesystem modification: Running from a package can expose application content as read-only, but that does not prevent code from using an attached write-capable identity against the backing storage.

Accordingly, denying the runtime principal management-plane access to the Function App protects configuration from that principal, but it does not solve deployment-container write access.

Supported architecture for strict separation

For an Azure Functions architecture where runtime code only reads an independently published artifact, use a Premium or Dedicated App Service plan with an external package URL, rather than Flex Consumption:

1. A CI/CD deployment principal writes a versioned ZIP to a private Blob container.
2. The Function App’s managed identity receives only Storage Blob Data Reader, preferably scoped to the package blob or dedicated container.
3. Set WEBSITE_RUN_FROM_PACKAGE to the package’s Blob URL.
4. If using a user-assigned identity, set WEBSITE_RUN_FROM_PACKAGE_BLOB_MI_RESOURCE_ID to that identity’s resource ID.
5. Keep the deployment principal independent from every identity attached to the Function App.
6. Give runtime identities no management-plane permission to modify Function App configuration.
7. Publish packages under immutable/versioned names rather than replacing a blob in place.

The Functions package-deployment documentation explicitly supports fetching an external package with a managed identity assigned Storage Blob Data Reader on the package blob.^5^ External package URLs are not supported on Flex Consumption, so this requires a different hosting plan.^5^

An alternative is Azure Container Apps: publish images through an independent CI/CD identity with registry push rights, while the workload identity receives only AcrPull. Container Apps documents this split between the pipeline’s push authorization and the application’s managed-identity pull authorization.^6^ This is a container-image architecture rather than Flex package deployment, but it directly models the required writer/reader separation.

For a formal product-level statement specifically guaranteeing this threat boundary, open a Microsoft support request for Azure Functions and ask for confirmation that Flex Consumption currently has no deployment-service-only identity or read-only deployment-storage identity. The published Flex contract itself does not document either capability.

References

1. Use managed identities for App Service and Azure Functions
2. Create and manage function apps in the Flex Consumption plan (programming-language-csharp)
3. Azure built-in roles for Storage
4. Azure built-in roles
5. Package-based deployment for Azure Functions (premium-plan)
6. Deploy to Azure Container Apps from Azure Pipelines