Securing VNet-Integrated Azure Functions with Blob Triggers: Private Endpoints and No Public Access

[Windows Server]

In modern cloud architectures, security and network isolation are critical considerations when deploying Azure Functions. Many organizations leverage VNet integration to enhance security by restricting outbound traffic and ensuring controlled access to resources. However, when using Blob Triggered Azure Functions with an Azure Storage Account configured with Private Endpoints and no public access, additional configurations are required to maintain seamless communication. This blog explores the key challenges and best practices for enabling Blob Triggered Azure Functions in a fully private network environment, ensuring secure and reliable execution.

Behind the scenes

When public access is enabled for an Azure Storage Account, Azure Functions can communicate with it directly over the public internet using the storage account's connection string or managed identity. This allows seamless access to blobs, queues, and tables without requiring any additional networking configurations. But when there is business need to secure network parameter and run services in the scope of VNet there are some additional settings required and that's what we are going to discuss now.

Azure Functions can securely communicate with Azure services using private endpoints, which provide private IP addresses within a Virtual Network (VNet) to restrict traffic to the Microsoft backbone. When an Azure Function is integrated with a VNet using VNet Integration, it can access private endpoints within the VNet. The private endpoint assigns a private IP address from the VNet subnet to the associated Azure service (e.g., Azure Storage, Cosmos DB, Key Vault), allowing traffic to bypass public endpoints entirely. Azure Private DNS plays a critical role in resolving the fully qualified domain names (FQDNs) of these services to their corresponding private IP addresses. When the Azure Function attempts to connect to an Azure service, DNS resolution occurs via the linked Private DNS Zone, which contains the private IP mappings for the private endpoint. The Function App, if configured correctly, queries the Azure-provided DNS resolver or a custom DNS server that forwards requests to the Private DNS Zone, ensuring that requests to the service resolve to the private IP instead of the public IP. This setup ensures secure, low-latency communication within the VNet while maintaining strict access controls. Additionally, network security groups (NSGs) and route tables can be applied to further control traffic flow between the Function App and the private endpoints, preventing unintended public exposure.

Configuring Storage Connections for Blob Trigger

Azure Functions makes sure that workloads are fault tolerant. So, it automatically retries a blob-triggered function up to five times in case of failures. If the function still fails after these attempts, Azure Functions writes the corresponding blob details into a dedicated queue named: webjobs-blobtrigger-poison

This ensures that failed blobs are logged for further investigation and processing, preventing them from causing continuous execution failures. The AzureWebJobsStorage connection string is used internally to manage blobs and queues required for the Blob Trigger functionality. 

However, in case of VNet-integrated Azure Functions, it is not immediately apparent that Azure Queue Storage Private Endpoints must also be configured when using Blob Triggered Functions. However, as outlined above, this configuration is crucial to ensure that the Azure Function can correctly query Azure-provided DNS resolver to find the right Azure storage queue and route poison messages to the designated queue resource, maintaining reliability and seamless failure handling within a secure network environment.

Conclusion

In conclusion, securing Azure Blob Triggered Functions within a VNet-integrated environment requires careful configuration of private endpoints, DNS resolution, and storage access to ensure seamless communication while maintaining strict security controls. Unlike public access scenarios, where functions can directly interact with storage accounts over the internet, a private network setup demands proper integration of Azure Private DNS and Queue Storage Private Endpoints to facilitate reliable function execution and failure handling. By implementing these best practices, organizations can achieve a fully secure, resilient, and high-performing serverless architecture that adheres to enterprise security and compliance requirements.

View the full article