Azure Policies can restrict which service endpoints are allowed for Azure Storage accounts.
Let’s see this in action. Imagine you have a strict security requirement: all Azure Storage accounts in your subscription must only be accessible from within Azure, meaning no public internet access. You can enforce this using an Azure Policy.
First, you need to define the policy. We’ll use a built-in policy for this example, but you can create custom ones too. The policy we’re interested in is "Storage accounts should restrict network access" (policy definition ID: 20877307-7265-4397-9320-073922771597). This policy checks the networkAcls property of a storage account.
Here’s how you’d assign this policy to a specific scope, like a resource group or your subscription, using Azure CLI:
az policy assignment create --name "restrict-storage-endpoints" --display-name "Restrict Storage Endpoints to Private Access" --policy "20877307-7265-4397-9320-073922771597" --scope "/subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/YOUR_RESOURCE_GROUP_NAME"
Replace YOUR_SUBSCRIPTION_ID and YOUR_RESOURCE_GROUP_NAME with your actual values.
Once assigned, this policy will audit existing storage accounts and prevent the creation of new ones that violate the rule. A violation occurs if a storage account is configured to allow access from all networks (the default) or if public network access is explicitly enabled. The policy enforces that the allowBlobPublicAccess property must be false and that bypass should be set to AzureServices or Microsoft.Storage in the networkAcls if you are using private endpoints. More commonly, this policy is used to enforce that public network access is disabled.
The mental model here is about defining "desired state" for your Azure resources and then using Azure Policies to automatically enforce that state. The policy acts as a continuous auditor and enforcer. It checks resources against your defined rules and either flags non-compliant resources (audit) or prevents them from being created or modified to be non-compliant (deny). For network access control on storage accounts, this means ensuring that the publicNetworkAccess property is set to Disabled or Allowed only for specific virtual networks or IP addresses, effectively restricting the service endpoints.
The networkAcls property on a storage account is a powerful object. It allows you to define granular network access rules. You can specify whether to allow access from All networks, Selected networks (which can include specific virtual networks or IP ranges), or None. When you choose Selected networks, you can also specify if you want to allow Azure services to bypass these restrictions. This bypass setting is crucial when you want services like Azure Functions or Azure Batch to access your storage account without needing to configure complex network peering or public IP rules.
Consider a scenario where you’ve just created a new storage account and are configuring its network settings. By default, public access might be enabled. If an Azure Policy with the 20877307-7265-4397-9320-073922771597 definition is assigned to the scope containing this new storage account, the policy engine will immediately evaluate the storage account’s configuration. If publicNetworkAccess is set to Enabled, the policy will flag it as non-compliant. If the policy is assigned with Deny effect (rather than Audit), the creation or update operation that would result in public access being enabled would be blocked.
The key lever you control with this policy is the publicNetworkAccess property of the storage account. Setting this to Disabled is the most stringent restriction, ensuring that access is only permitted via private endpoints or service endpoints configured within your virtual networks. Setting it to Enabled allows you to then specify virtualNetworkRules and ipRules to grant access to specific subnets or IP addresses, further refining the allowed service endpoints.
When you’re setting up network rules for a storage account, the order of precedence matters. If you have both virtualNetworkRules and ipRules defined, and the client request comes from an IP that is also within an allowed virtual network, the ipRules will be checked first. If the IP is not explicitly allowed by an ipRule, it will then check the virtualNetworkRules. However, if publicNetworkAccess is set to Disabled, neither IP rules nor virtual network rules configured on the storage account itself will grant access; access must be exclusively through private endpoints or service endpoints.
The next concept you’ll want to explore is how to use custom Azure Policies to enforce more complex network restrictions, such as requiring specific service endpoints (like Microsoft.Storage) to be configured on subnets within your virtual networks.