Forum Discussion
Azure network security perimeter with storage accounts and Runbooks
I know this is a preview feature, and I don't know if it will be fixed in the future.
The problem arises when you try to secure traffic between Azure serverless runbooks and a storage account.
No matter what configuration you use, the runbook will access the storage account using a 10.x.x.x IP.
That means you can't secure traffic using storage account firewall rules since private IPs are not allowed.
I thought that with Azure's network security perimeter, this would be fixed since you can put your storage inside and specify that only resources from the subscription are allowed to access it.
But no, it still doesn't work.
Is Microsoft aware of this issue? I know you can use hybrid workers to get a public IP and so on, but that destroys the power of runbooks if you can't use the serverless option.
Thanks for your time!
1 Reply
Yes, below the current limitations and workarounds:
Current Limitation
- Azure serverless runbooks access storage accounts using internal private IPs (e.g., 10.x.x.x), which are not supported by storage account firewall rules.
- Even with the Azure network security perimeter feature, private IPs from Azure's internal infrastructure cannot be used to enforce firewall rules.
Workarounds
- Private Endpoints: Assign a private endpoint to your storage account. This allows traffic to flow securely within your virtual network and bypasses the need for public IPs.
- Trusted Microsoft Services: Enable the "Allow trusted Microsoft services" option in the storage account firewall settings. This allows Azure Automation (including serverless runbooks) to access the storage account without specific IP rules.
- Hybrid Workers: While not ideal for serverless scenarios, hybrid workers can provide a public IP for accessing the storage account. This is a workaround but compromises the serverless nature of runbooks.
