The behavior you’re seeing is expected for Databricks managed workspace storage accounts.
The storage accounts that start with db* are created and managed by Azure Databricks in a Microsoft-managed resource group. Because of this:
- Customers don’t have full RBAC permissions on those resources
- Certain operations (like associating a Network Security Perimeter) aren’t allowed
- Attempts to modify networking/security settings can return LinkedAuthorizationFailed (403)
So the 403 isn’t a misconfiguration - it’s happening because the resource is service-managed.
What this means for NSP
At this time, Network Security Perimeter association isn’t supported directly on Databricks-managed storage accounts. Those resources are governed by the Databricks service itself, not by customer-applied network perimeters.
Recommended approach
- Apply NSP to customer-managed storage accounts that your workloads access
- Follow Databricks guidance for serverless connectivity and firewall allow-listing
- If NSP enforcement is a hard requirement, raise a support ticket with Microsoft to confirm current supportability or roadmap, since this is service-level behavior
Hope this helps clarify why you’re hitting that error.