Cortex Cloud: Connectivity Disruption to Azure Storage Accounts during Cortex DSPM Scanning in Private Endpoint Environments

200

Created On 05/11/26 14:59 PM - Last Modified 07/10/26 14:54 PM

Cortex Cloud Data Security Assets

Cortex Cloud Data Security Objects

Cortex Cloud Data Security

Cortex Cloud SaaS

Cortex Cloud

Symptom

Unexpected 403 Forbidden or "Network Connection Refused" errors for applications accessing Azure Storage.
Disruption coincides with the onboarding or scheduled scanning of Cortex DSPM.
Automatic creation of new Private Endpoints (prefixed with private-endpoint-) within the Cortex-managed resource groups.
Existing connectivity via Private Endpoints fails despite no manual configuration changes to the application environment.

Environment

Cortex CLOUD V2.0

Cause

To perform data classification and scanning, Cortex DSPM automatically provisions a Private Endpoint to connect to the target Storage Account.
In Azure environments where Public Network Access is disabled and Service Endpoints are utilized, the introduction of a Private Endpoint can disrupt traffic flow for existing clients.
This is due to Azure's networking behavior where the creation of a Private Link can override DNS resolution (via Private DNS Zones) or trigger access constraints that invalidate the Service Endpoint path for clients not explicitly accounted for in the new Private Link configuration.

Resolution

By manually adding the Cortex Outpost VNet which follows the naming pattern <CortexResourceGroupName>-vnet-<Region> to your storage account's allowed networks, you ensure that scanning occurs over the Microsoft backbone using a Service Endpoint bypass, eliminating the need for a Private Endpoint.
- Note: This bypass applies to both Cloud Scan (Managed Outpost) and Unmanaged Outpost configurations.
Prerequisites
- Update Orchestrator: Ensure you have the latest version of the orchestrator/outpost deployed. Navigate to the Subscriptions page, click Update Required next to the subscription, and follow the prompts.
- Permissions: You must use an account with permissions to modify Networking rules (e.g., Storage Account Contributor or Owner) on the target Storage Account.

Implementation Option 1: Azure CLI (Automated)

Use these commands to explicitly trust the Outpost's VNet. This informs Cortex that a secure path exists, preventing it from attempting to create a Private Endpoint on the storage account.
Note: it is also possible to apply this change to a group of storage accounts in the region

# 1. Set the context to the subscription containing the
Storage Account
az account set --subscription
<STORAGE_ACCOUNT_SUBSCRIPTION_ID>
# 2. Add the network rule for the Cortex Outpost VNet
az storage account network-rule add \
--account-name <STORAGE_ACCOUNT_NAME> \
--resource-group <STORAGE_ACCOUNT_RESOURCE_GROUP> \
--subnet
"/subscriptions/<VNET_SUBSCRIPTION_ID>/resourceGroups/<VNET_RE
SOURCE_GROUP>/providers/Microsoft.Network/virtualNetworks/<VNE
T_NAME>/subnets/<SUBNET_NAME>"

Implementation Option 2: Azure Portal (Manual)
- Only applicable for Unmanaged Outposts.
  1. Log into the Azure Portal and navigate to the relevant Storage Account.
  2. In the left-hand menu, under Security + networking, click Networking.
  3. Under the Firewalls and virtual networks tab, ensure "Public network access" is set to Enabled from selected virtual networks and IP addresses.
  4. Click + Add existing virtual network.
  5. In the side panel, configure the following:
    1. Subscription: Select the subscription where the Cortex Outpost is hosted.
    2. Virtual network: Search for the VNet using the naming convention:
      <CortexResourceGroupName>-vnet-<Region> (e.g., f3dtirk3-vnet-eastus).
    3. Subnets: Select the scanning subnet for the region.
  6. Enable Service Endpoint: If prompted that the endpoint is missing, select the option to enable the Microsoft.Storage service endpoint for that subnet.
  7. Click Add, then click Save at the top of the page.

Additional Information