Azure network security perimeter with storage accounts and Runbooks

Question

Azure network security perimeter with storage accounts and Runbooks

JUFO 81

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!

Hari Babu Vattepally 2,480 Reputation points Microsoft External Staff

2025-03-18T11:39:59.6533333+00:00

Hi @JUFO,

I see that you are facing an issue with Azure serverless runbooks while accessing a storage account using private IP.

We see that there are Restrictions for IP Network Rules as follows:

IP address ranges reserved for private networks (as defined in RFC 1918) aren't allowed in IP rules. Private networks include addresses that start with 10, 172.16 to 172.31, and 192.168.

So, Storage account firewalls do not support private IPs, which creates a challenge in securing traffic between serverless runbooks and storage accounts.

Azure Storage account firewall needs either public IPs or virtual network integration to access, as the private IPs from Azure's internal infrastructure are not supported.

In order to get this issue fixed, use Private end points for storage account, which assigns a private IP from your virtual network to the storage account. Making sure that all the traffic remains within the Azure backbone.

As shown in the below screen shot, you can manage virtual network and access rules for storage accounts through the Portal.

In the Storage account Firewall settings under Exceptions, make sure to enable the option to Allow access from Trusted Microsoft Services list to access this storage account. So that this will allow Azure Automation to access the Storage account without any specific IP rules.

Before applying the rules to the storage account, please make sure that the user should have appropriate permissions for the subnets that being added. A Storage Account Contributor or a user who has permission to the Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action Azure resource provider operation can apply a rule by using a custom Azure role.

Yes, Microsoft is aware of the limitations related to the network security perimeter, especially in preview. The preview version is provided without a service level agreement, and which is not recommended for production workloads. So, certain features might not be supported or might have constrained capabilities.

I hope by following the above by configuring Private Endpoints for your storage account and also make sure that your runbooks operate within a virtual network that has access to the private endpoint will work in resolving the issue. This Approach will also maintain the serverless nature of runbooks while securing the traffic.

Please let us know in the comments below, if the issue is resolved or still persists. We will be glad to assist you closely.

Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Hari Babu Vattepally 2,480 Reputation points Microsoft External Staff

2025-03-19T10:04:57.8633333+00:00

Hi @JUFO,

Following up to see if the above answer was helpful. If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know.
JUFO 81 Reputation points

2025-03-19T10:58:32.7066667+00:00

I think I didn’t make myself clear. What I meant is that when using a serverless runbook (with no VNet integration at all and no hybrid workers), the way a runbook interacts with storage accounts is always through a private IP, like 10.x.x.x.

I’m not sure if that’s clear. So, for example, when you try to create a blob in a storage account using a serverless runbook, the runbook always attempts to use a 10.x.x.x IP. However, that type of IP cannot be set in the storage account firewall since it is a private IP.

The same thing happens with Perimeter.

You can try using the REST API from the runbook, but its internal DNS forces it to connect to the storage account internally.

It doesn’t matter if you try to determine the public IP the runbook is using because the moment it connects to a storage account, it does so using a 10.x.x.x IP, not its public IP.
Hari Babu Vattepally 2,480 Reputation points Microsoft External Staff

2025-03-19T11:43:34.2933333+00:00
Hi @JUFO

When using a serverless runbook without VNet integration or hybrid workers, runbook interacts with Azure storage accounts via internal private IP addresses (e.g., 10.x.x.x). These private IPs cannot be added to the storage account firewall settings, which creates a challenge for granting access. The storage account firewall is designed to allow public IP addresses or specific virtual network configurations, and private IPs are not permitted.

Regarding the Azure network security perimeter, which restricts public network access to PaaS resources, it's important to note that internal communication from the runbook to the storage account might not fit the expected access configurations. The security perimeter is designed for managing public access and may not fully support internal private IP communications from serverless runbooks.

To address this issue, please consider using private endpoints or configuring the storage account to allow access from specific public IPs. While serverless runbooks use private IPs for communication, these solutions can be implemented effectively.

For additional reference:

What is a network security perimeter?

Configure network access to Azure Storage

Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
JUFO 81 Reputation points

2025-03-19T11:59:47.26+00:00

Thanks a lot for you time, but I think that is not the solution:

Configuring the storage account to allow access from specific public IPs doesn't work because serverless runbooks use private IPs to communicate with storage accounts. Even if the runbook has a public IP, it is never used for this communication. Or even yo configure storage to have internet routing.

Private endpoints work for storage accounts only if you use hybrid workers since the private endpoint for a serverless runbook is inbound-only, not outbound.

Therefore, I guess, the only way to secure communication between runbooks and storage accounts is by using hybrid workers, what I'm trirying to avoid. From there, you can either use the worker's public IP or a private link for communication.

My question was about the network security perimeter, which supposedly secures communication within the same subscription. However, if you are using a serverless runbook, it does not work, no matter what configuration you try.
JUFO 81 Reputation points

2025-03-19T16:08:46.0733333+00:00

Thanks for your answer and for clarifying that using hybrid workers is the only option.

Is there no roadmap to address this issue? It is something that makes no sense
Hari Babu Vattepally 2,480 Reputation points Microsoft External Staff

2025-03-20T12:09:37.06+00:00

Hi @JUFO,

Apologies for delay in reply,

Unfortunately, there is no publicly available roadmap to resolve the issue. To push for a solution, please provide feedback to Microsoft through Azure Feedback Portal. Sharing detailed feedback can help highlight the importance of this issue and potentially expedite the development of a solution.

It is important to communicate the impact and urgency of this matter clearly to Microsoft, as user feedback plays a crucial role in their prioritization process. By doing so, you contribute to the improvement of their services, which can benefit all users facing similar challenges.

Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Accepted answer

0 additional answers

Your answer

Hari Babu Vattepally 2,480 Reputation points Microsoft External Staff

2025-03-19T10:04:57.8633333+00:00

Hi @JUFO,

Following up to see if the above answer was helpful. If this answers your query, do click Accept Answer and Yes for was this answer helpful. And, if you have any further query do let us know.
JUFO 81 Reputation points

2025-03-19T10:58:32.7066667+00:00

I think I didn’t make myself clear. What I meant is that when using a serverless runbook (with no VNet integration at all and no hybrid workers), the way a runbook interacts with storage accounts is always through a private IP, like 10.x.x.x.

I’m not sure if that’s clear. So, for example, when you try to create a blob in a storage account using a serverless runbook, the runbook always attempts to use a 10.x.x.x IP. However, that type of IP cannot be set in the storage account firewall since it is a private IP.

The same thing happens with Perimeter.

You can try using the REST API from the runbook, but its internal DNS forces it to connect to the storage account internally.

It doesn’t matter if you try to determine the public IP the runbook is using because the moment it connects to a storage account, it does so using a 10.x.x.x IP, not its public IP.
Hari Babu Vattepally 2,480 Reputation points Microsoft External Staff

2025-03-19T11:43:34.2933333+00:00

Hi @JUFO

When using a serverless runbook without VNet integration or hybrid workers, runbook interacts with Azure storage accounts via internal private IP addresses (e.g., 10.x.x.x). These private IPs cannot be added to the storage account firewall settings, which creates a challenge for granting access. The storage account firewall is designed to allow public IP addresses or specific virtual network configurations, and private IPs are not permitted.

Regarding the Azure network security perimeter, which restricts public network access to PaaS resources, it's important to note that internal communication from the runbook to the storage account might not fit the expected access configurations. The security perimeter is designed for managing public access and may not fully support internal private IP communications from serverless runbooks.

To address this issue, please consider using private endpoints or configuring the storage account to allow access from specific public IPs. While serverless runbooks use private IPs for communication, these solutions can be implemented effectively.

For additional reference:

What is a network security perimeter?

Configure network access to Azure Storage

Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
JUFO 81 Reputation points

2025-03-19T11:59:47.26+00:00

Thanks a lot for you time, but I think that is not the solution:

Configuring the storage account to allow access from specific public IPs doesn't work because serverless runbooks use private IPs to communicate with storage accounts. Even if the runbook has a public IP, it is never used for this communication. Or even yo configure storage to have internet routing.

Private endpoints work for storage accounts only if you use hybrid workers since the private endpoint for a serverless runbook is inbound-only, not outbound.

Therefore, I guess, the only way to secure communication between runbooks and storage accounts is by using hybrid workers, what I'm trirying to avoid. From there, you can either use the worker's public IP or a private link for communication.

My question was about the network security perimeter, which supposedly secures communication within the same subscription. However, if you are using a serverless runbook, it does not work, no matter what configuration you try.
JUFO 81 Reputation points

2025-03-19T16:08:46.0733333+00:00

Thanks for your answer and for clarifying that using hybrid workers is the only option.

Is there no roadmap to address this issue? It is something that makes no sense
Hari Babu Vattepally 2,480 Reputation points Microsoft External Staff

2025-03-20T12:09:37.06+00:00

Hi @JUFO,

Apologies for delay in reply,

Unfortunately, there is no publicly available roadmap to resolve the issue. To push for a solution, please provide feedback to Microsoft through Azure Feedback Portal. Sharing detailed feedback can help highlight the importance of this issue and potentially expedite the development of a solution.

It is important to communicate the impact and urgency of this matter clearly to Microsoft, as user feedback plays a crucial role in their prioritization process. By doing so, you contribute to the improvement of their services, which can benefit all users facing similar challenges.

Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Answer 1

Hi @JUFO,

The issue with Azure network security perimeter and serverless runbooks is a known limitation. When using serverless runbooks, communication with Azure Storage accounts generally goes through private IPs, which complicates the use of public IP configurations.

As you mentioned, private endpoints for storage accounts only allow inbound communication. This means that serverless runbooks cannot use these endpoints for outbound communication. Therefore, hybrid workers are required to ensure secure communication between runbooks and storage accounts.

Coming to your actually question. Yes, the network security perimeter aims to restrict public access and ensure secure communication within the same subscription. However, it is not effective for serverless runbooks, as they depend on private IPs for their communication. So, the only reliable method for securing this communication is through hybrid workers, which can use either public IPs or private links.

Hari Babu Vattepally 2,480 Reputation points Microsoft External Staff

2025-03-20T14:52:53.51+00:00

Hi @JUFO ,

Your contribution is highly appreciated. Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Share via

Azure network security perimeter with storage accounts and Runbooks

0 additional answers

Your answer