Forum Discussion
What would be the expected behavior for an NSP?
I'm using a network security perimeter in Azure.
In the perimeter there are two resources assigned: A storage Account and An Azure SQL Databse.
I'm using the BULK INSERT dbo.YourTable FROM 'sample_data.csv' getting data from the storage account.
The NSP is enforced for both resources, so the public connectivity is denied for resources outside the perimeter
I have experienced this behavior: the azure SQL CANNOT access the storage account when I run the command. I resolved using:
- I need to add an outbound rule in the NSP to reach the storage fqdn
- I need to add an inbound rule in the NSP to allow the public IP of the SQL Azure
When I do 1 and 2, azure SQL is able to pump data from the storage.
IMHO this is not the expected behavior for two resources in the NSP. I expect that, as they are in the same NSP, they can communicate to each other.
I have experienced a different behavior when using keyvault in the same NSP. I'm using the keyvault to get the keys for encryption for the same storage. For the key vault, i didn't have to create any rule to make it able to communicate to the storage, as they are in the same NSP.
I know, Azure SQL is in preview for the NSP and the keyvault in GA, but I want to ask if the experienced behavior (the SQL CANNOT connect to the storage even if in the same NSP) is due to a unstable or unimplemented feature, or I'm missing something? What is the expected behavior?
Thank you community!!
2 Replies
Your expectation is broadly correct: resources in the same Network Security Perimeter profile should have mutual network access, but NSP does not replace data-plane authentication. Implicit member-to-member access is designed for managed identities and role assignments; account keys, SAS tokens, or non-onboarded services can still require rules. For BULK INSERT, configure a managed identity for the Azure SQL logical server, grant it Storage Blob Data Contributor on the container or account, and use a database-scoped credential with managed identity rather than a storage key. Confirm SQL Database and storage are associated with the same profile and mode, then inspect NSP diagnostic logs for denied flows. Azure SQL’s NSP integration remains documented as preview. If the managed-identity path still requires public-IP and FQDN exceptions, keep them during testing, capture denied-flow records, and open Azure support; that would indicate a preview limitation or defect, not intended same-perimeter behavior.
The expected behavior of a Network Security Perimeter (NSP) is that resources inside the same perimeter should be able to communicate with each other without additional public inbound/outbound rules. However, because Azure SQL Database support for NSP is still in preview, the seamless communication you observed with Key Vault (GA) is not yet fully implemented for SQL. What you are seeing, having to add explicit rules for SQL to reach Storage which is a limitation of the preview state, not the final intended design.
Network Security Perimeter for Azure Storage | Microsoft Learn
Network Security Perimeter - Azure SQL Database | Microsoft Learn
