Add private connectivity to Azure IoT Operations

This article describes how to add private connectivity to an existing Azure IoT Operations deployment. Follow the sections in order:

These scenarios apply to environments with a single Arc-enabled Kubernetes cluster. There's no Purdue-style network segmentation, no proxy chaining across layers, and no Envoy deployment. If you have a layered network topology, see Tutorial: Deploy Azure IoT Operations in a layered network with private connectivity instead.

Prerequisites

• An existing Azure IoT Operations deployment on an Arc-connected Kubernetes cluster. The cluster must be healthy with all Azure IoT Operations pods running.
• An Azure subscription with sufficient permissions to create private endpoints, private DNS zones, and role assignments (typically Owner or Contributor + User Access Administrator).
• Azure CLI and kubectl installed on your admin or jump machine.
• An Azure VNet with network connectivity from your cluster. If your cluster runs on Azure VMs within the same VNet or a peered VNet, this connectivity is already in place.
• (Optional) An Azure Event Grid namespace with MQTT enabled. Needed only if you route data flow traffic to Event Grid in Configure data flow destinations with private endpoints.
• (Optional) An Azure Firewall with explicit proxy enabled in your VNet, reachable from your cluster. Required only if you follow the Arc Gateway + Explicit Proxy tab for fully private connectivity with no public internet exposure.

The Azure CLI examples in this article use environment variables so that you can set each value once and then copy and paste the commands as-is. If you're using the Azure IoT Operations Codespaces environment from the quickstart, these variables are already set for you and you can skip this step. Otherwise, set the following environment variables in your shell before you run the commands.

The following scripts set the most commonly used environment variables:

SUBSCRIPTION_ID=<subscription-id>
RESOURCE_GROUP=<resource-group-name>
AIO_INSTANCE_NAME=<instance-name>
CLUSTER_NAME=<cluster-name>
LOCATION=<region>

$SUBSCRIPTION_ID = "<subscription-id>"
$RESOURCE_GROUP = "<resource-group-name>"
$AIO_INSTANCE_NAME = "<instance-name>"
$CLUSTER_NAME = "<cluster-name>"
$LOCATION = "<region>"

You only need to set the variables that this article uses. This article might use additional environment variables for resource names that you choose. The article explains how to set them where they're introduced.

This article also uses environment variables for the network and Azure resources that you choose, including VNET_RESOURCE_GROUP, VNET_NAME, SUBNET_NAME, STORAGE_ACCOUNT_NAME, KEY_VAULT_NAME, EVENT_GRID_NAMESPACE, ARC_GATEWAY_RESOURCE_ID, CUSTOM_LOCATIONS_OID, FIREWALL_POLICY_NAME, CLUSTER_SUBNET_CIDRS, FIREWALL_PRIVATE_IP, PROXY_PORT, TOPIC_SPACE_NAME, AIO_IDENTITY_PRINCIPAL_ID, DATAFLOW_NAME, CONFIG_FILE, and CLUSTER_HOST_IP. Set each one before you run the related commands.

Set up Arc Gateway

Azure Arc Gateway consolidates the ~200+ Azure endpoints that Arc agents and extensions require into a single gateway URL. This significantly simplifies your firewall allow list, instead of allowing 200+ individual FQDNs, you allow approximately 9.

Step 1: Create an Arc Gateway resource

If you don't already have an Arc Gateway resource, create one. You need the gateway resource ID when you connect the cluster in the next section. For creation steps, see Create the Arc Gateway resource.

For the list of FQDNs that you must allow through your firewall when using Arc Gateway, see Allowed endpoints with Arc Gateway.

Step 2: Retrieve the custom locations Object ID

The --custom-locations-oid parameter you use when connecting the cluster requires the Object ID (OID) of the Azure Arc Custom Locations service principal.

To find it:

az ad sp show --id bc313c14-388c-4e7d-a58e-70017303ee3b --query id -o tsv

Allow the operations experience to access your resources

Before you restrict access to your resources with private endpoints, allow the Azure IoT Operations operations experience web UI to reach Azure Key Vault, Azure Storage, and Schema Registry. The operations experience accesses these resources on your behalf:

• Azure Key Vault to manage secrets.
• Azure Storage and Schema Registry to read and write message schemas in the storage account that backs your schema registry.

When you configure these resources to use a private endpoint and firewall, the operations experience can no longer reach them over the public internet. This configuration causes errors when you manage secrets or schemas in the web UI. To keep the operations experience working, set each resource's firewall to Public access: Selected networks and IP addresses and add the operations experience IP addresses to the resource's firewall allow list.

The operations experience IP addresses are allocated by region:

Configure the firewall allow list for each resource before you create its private endpoint. The following examples add all of the operations experience IP addresses.

Azure Key Vault

az keyvault update \
  --resource-group $RESOURCE_GROUP \
  --name $KEY_VAULT_NAME \
  --default-action Deny

DOE_IP_ADDRESSES=(48.211.120.64 72.145.25.40 128.24.193.24 72.145.132.248 57.154.126.80)

for DOE_IP_ADDRESS in "${DOE_IP_ADDRESSES[@]}"; do
  az keyvault network-rule add \
    --resource-group $RESOURCE_GROUP \
    --name $KEY_VAULT_NAME \
    --ip-address $DOE_IP_ADDRESS
done

Azure Storage and Schema Registry

The schema registry is backed by an Azure Storage account. Apply the firewall configuration to that storage account so the operations experience can read and write schemas. Keep the trusted Azure services bypass enabled so the schema registry can continue to reach storage.

az storage account update \
  --resource-group $RESOURCE_GROUP \
  --name $STORAGE_ACCOUNT_NAME \
  --public-network-access Enabled \
  --default-action Deny \
  --bypass AzureServices

DOE_IP_ADDRESSES=(48.211.120.64 72.145.25.40 128.24.193.24 72.145.132.248 57.154.126.80)

for DOE_IP_ADDRESS in "${DOE_IP_ADDRESSES[@]}"; do
  az storage account network-rule add \
    --resource-group $RESOURCE_GROUP \
    --account-name $STORAGE_ACCOUNT_NAME \
    --ip-address $DOE_IP_ADDRESS
done

Verify the operations experience can access your resources

After you enable the firewall restrictions, confirm that the operations experience can still reach the required resources:

1. Go to the operations experience web UI and open your Azure IoT Operations instance.
2. Select Secrets and confirm that the operations experience loads the secrets stored in Azure Key Vault without a firewall or authorization error.
3. Select Schemas and confirm that the operations experience loads existing schemas and that you can create a schema. Success confirms access to the schema registry storage account.

If any page returns an access or firewall error, verify that you added all of the operations experience IP addresses to the resource's firewall allow list and that public access is set to Selected networks and IP addresses. For diagnostics when Secrets or Schemas returns an access or firewall error, see The operations experience can't load or manage secrets or schemas after enabling private endpoints.

Create private endpoints and DNS zones

Azure IoT Operations uses a storage account (schema registry) and Key Vault (secret sync) at runtime. Create private endpoints and DNS zones for these resources so all traffic routes privately. Once you link the private DNS zones to your VNet, your cluster automatically resolves these services to their private IPs.

Step 1: Create private endpoints

Create private endpoints for the storage account, Key Vault, and Event Grid so all traffic to these services routes privately.

Azure Blob Storage

az network private-endpoint create \
  --name pe-storage-blob \
  --resource-group $RESOURCE_GROUP \
  --location $LOCATION \
  --subnet "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$SUBNET_NAME" \
  --private-connection-resource-id "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Storage/storageAccounts/$STORAGE_ACCOUNT_NAME" \
  --group-id blob \
  --connection-name pe-conn-storage-blob

Azure Key Vault

az network private-endpoint create \
  --name pe-keyvault \
  --resource-group $RESOURCE_GROUP \
  --location $LOCATION \
  --subnet "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$SUBNET_NAME" \
  --private-connection-resource-id "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.KeyVault/vaults/$KEY_VAULT_NAME" \
  --group-id vault \
  --connection-name pe-conn-keyvault

Event Grid namespace

az network private-endpoint create \
  --name pe-eventgrid \
  --resource-group $RESOURCE_GROUP \
  --location $LOCATION \
  --subnet "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$SUBNET_NAME" \
  --private-connection-resource-id "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.EventGrid/namespaces/$EVENT_GRID_NAMESPACE" \
  --group-id topicspace \
  --connection-name pe-conn-eventgrid

Step 2: Configure Private DNS Zones

Create Private DNS Zones so Azure service FQDNs resolve to Private Endpoint IPs. Link each zone to your VNet and create DNS zone groups so the Private Endpoint A records are registered automatically.

Azure Blob Storage

az network private-dns zone create \
  --resource-group $RESOURCE_GROUP \
  --name privatelink.blob.core.windows.net

az network private-dns link vnet create \
  --resource-group $RESOURCE_GROUP \
  --zone-name privatelink.blob.core.windows.net \
  --name storage-dns-link \
  --virtual-network "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME" \
  --registration-enabled false

az network private-endpoint dns-zone-group create \
  --resource-group $RESOURCE_GROUP \
  --endpoint-name pe-storage-blob \
  --name storage-zone-group \
  --private-dns-zone "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Network/privateDnsZones/privatelink.blob.core.windows.net" \
  --zone-name blob

Azure Key Vault

az network private-dns zone create \
  --resource-group $RESOURCE_GROUP \
  --name privatelink.vaultcore.azure.net

az network private-dns link vnet create \
  --resource-group $RESOURCE_GROUP \
  --zone-name privatelink.vaultcore.azure.net \
  --name keyvault-dns-link \
  --virtual-network "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME" \
  --registration-enabled false

az network private-endpoint dns-zone-group create \
  --resource-group $RESOURCE_GROUP \
  --endpoint-name pe-keyvault \
  --name keyvault-zone-group \
  --private-dns-zone "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Network/privateDnsZones/privatelink.vaultcore.azure.net" \
  --zone-name vault

Event Grid

az network private-dns zone create \
  --resource-group $RESOURCE_GROUP \
  --name privatelink.ts.eventgrid.azure.net

az network private-dns link vnet create \
  --resource-group $RESOURCE_GROUP \
  --zone-name privatelink.ts.eventgrid.azure.net \
  --name eventgrid-dns-link \
  --virtual-network "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME" \
  --registration-enabled false

az network private-endpoint dns-zone-group create \
  --resource-group $RESOURCE_GROUP \
  --endpoint-name pe-eventgrid \
  --name eventgrid-zone-group \
  --private-dns-zone "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Network/privateDnsZones/privatelink.ts.eventgrid.azure.net" \
  --zone-name eventgrid

For the full list of private DNS zone names, see Azure Private DNS Zone values.

Update Arc connectivity

With private endpoints and DNS in place, update your existing Arc connection to use Arc gateway. Choose the tab that matches your connectivity approach:

• Arc Gateway only — The cluster connects through Arc Gateway with a simplified firewall allow list (~9 FQDNs), but outbound traffic still uses public internet paths.
• Arc Gateway + Explicit Proxy — All outbound traffic routes through Azure Firewall Explicit Proxy over your private network with no public internet exposure.

Both tabs build on Set up Arc Gateway. Complete that section first to create the Arc Gateway resource and retrieve the custom locations OID.

az connectedk8s update \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP \
  --gateway-resource-id $ARC_GATEWAY_RESOURCE_ID

az connectedk8s connect \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP \
  --location $LOCATION \
  --custom-locations-oid $CUSTOM_LOCATIONS_OID \
  --enable-oidc-issuer \
  --enable-workload-identity \
  --disable-auto-upgrade \
  --gateway-resource-id $ARC_GATEWAY_RESOURCE_ID

az network firewall policy rule-collection-group create \
  --name ArcRules \
  --policy-name $FIREWALL_POLICY_NAME \
  --resource-group $RESOURCE_GROUP \
  --priority 100

az network firewall policy rule-collection-group collection add-filter-collection \
  --rule-collection-group-name ArcRules \
  --policy-name $FIREWALL_POLICY_NAME \
  --resource-group $RESOURCE_GROUP \
  --name AllowArc \
  --collection-priority 100 \
  --action Allow \
  --rule-type ApplicationRule \
  --rule-name AllowArcEndpoints \
  --source-addresses "$CLUSTER_SUBNET_CIDRS" \
  --protocols Https=443 \
  --target-fqdns "*.gw.arc.azure.com" "management.azure.com" "*.his.arc.azure.com" "*.dp.kubernetesconfiguration.azure.com" "login.microsoftonline.com" "mcr.microsoft.com" "*.data.mcr.microsoft.com" "gbl.his.arc.azure.com" "*.login.microsoft.com"

export HTTPS_PROXY=http://$FIREWALL_PRIVATE_IP:$PROXY_PORT
export HTTP_PROXY=http://$FIREWALL_PRIVATE_IP:$PROXY_PORT
export NO_PROXY=localhost,127.0.0.1,169.254.169.254,.svc,.local,$CLUSTER_SUBNET_CIDRS

az connectedk8s update \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP \
  --proxy-https $HTTPS_PROXY \
  --proxy-http $HTTP_PROXY \
  --proxy-skip-range $NO_PROXY \
  --gateway-resource-id $ARC_GATEWAY_RESOURCE_ID

az connectedk8s connect \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP \
  --location $LOCATION \
  --custom-locations-oid $CUSTOM_LOCATIONS_OID \
  --enable-oidc-issuer \
  --enable-workload-identity \
  --disable-auto-upgrade \
  --proxy-https $HTTPS_PROXY \
  --proxy-http $HTTP_PROXY \
  --proxy-skip-range $NO_PROXY \
  --gateway-resource-id $ARC_GATEWAY_RESOURCE_ID

Configure data flow destinations with private endpoints

Azure IoT Operations data flows send telemetry to cloud destinations like Azure Event Grid, Azure Event Hubs, Azure Data Explorer, Data Lake Storage Gen2, and Microsoft Fabric OneLake. By default, data flows connect to these services over their public endpoints. To keep traffic private, create private endpoints for each destination and ensure DNS resolves to the private IPs.

The following table shows supported data flow destinations and the private DNS zone, group ID, and port for each:

The steps in the following section use Azure Event Grid as the example. The same pattern applies to every destination, substitute the values from the preceding table.

Step 1: Create an Event Grid namespace

If you don't already have one, create an Event Grid namespace with MQTT (topic spaces) enabled:

az eventgrid namespace create \
  --name $EVENT_GRID_NAMESPACE \
  --resource-group $RESOURCE_GROUP \
  --location $LOCATION \
  --topic-spaces-configuration state=Enabled \
  --sku name=Standard capacity=1

Then create a topic space. For testing, you can use the wildcard # as the topic template:

az eventgrid namespace topic-space create \
  --name $TOPIC_SPACE_NAME \
  --resource-group $RESOURCE_GROUP \
  --namespace-name $EVENT_GRID_NAMESPACE \
  --topic-templates "#"

Step 2: Assign RBAC for Event Grid

Grant the Azure IoT Operations managed identity the Event Grid role that matches your data flow direction:

• One-way (source → Event Grid): Assign EventGrid TopicSpaces Publisher.
• One-way (Event Grid → destination): Assign EventGrid TopicSpaces Subscriber.
• Bidirectional bridge: Assign both EventGrid TopicSpaces Publisher and EventGrid TopicSpaces Subscriber.

For a typical data flow that publishes telemetry to Event Grid:

az role assignment create \
  --assignee $AIO_IDENTITY_PRINCIPAL_ID \
  --role "EventGrid TopicSpaces Publisher" \
  --scope "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.EventGrid/namespaces/$EVENT_GRID_NAMESPACE"

Step 3: Disable public access on the Event Grid namespace

You already created the Event Grid private endpoint and DNS zone in Create private endpoints and DNS zones. Now, disable public access:

az eventgrid namespace update \
  --name $EVENT_GRID_NAMESPACE \
  --resource-group $RESOURCE_GROUP \
  --public-network-access Disabled

Verify that public access is disabled:

az eventgrid namespace show --name $EVENT_GRID_NAMESPACE --resource-group $RESOURCE_GROUP --query "publicNetworkAccess"

Step 4: Verify DNS resolves to a private IP

From your cluster node (or a VM in the same VNet), confirm the FQDN resolves to the private endpoint IP:

nslookup $EVENT_GRID_NAMESPACE.$LOCATION-1.ts.eventgrid.azure.net

The result should return an IP in your private address range (for example, 10.x.x.x), not a public IP. If it returns a public IP, check your private DNS zone linkage.

Step 5: Create the data flow endpoint for Event Grid

Create an Event Grid MQTT data flow endpoint. This action creates an endpoint that uses system-assigned managed identity authentication. The host uses the Event Grid namespace's MQTT hostname on port 8883. No special configuration is needed for Private Link - the data flow resolves the FQDN through DNS, which returns the private endpoint IP if your DNS zones are configured correctly.

az iot ops dataflow endpoint create eventgrid \
  --resource-group $RESOURCE_GROUP \
  --instance $AIO_INSTANCE_NAME \
  --name eventgrid-private-endpoint \
  --host $EVENT_GRID_NAMESPACE.$LOCATION-1.ts.eventgrid.azure.net

For more information, see Configure MQTT data flow endpoints for Event Grid.

Step 6: Create a data flow to test

Create a data flow that routes MQTT broker messages to the Event Grid destination.

{
  "mode": "Enabled",
  "operations": [
    {
      "operationType": "Source",
      "sourceSettings": {
        "endpointRef": "default",
        "dataSources": [
          "test/eventgrid"
        ]
      }
    },
    {
      "operationType": "Destination",
      "destinationSettings": {
        "endpointRef": "eventgrid-private-endpoint",
        "dataDestination": "test/eventgrid"
      }
    }
  ]
}

az iot ops dataflow apply \
  --resource-group $RESOURCE_GROUP \
  --instance $AIO_INSTANCE_NAME \
  --profile default \
  --name $DATAFLOW_NAME \
  --config-file $CONFIG_FILE

Step 7: Validate telemetry arrives at Event Grid

Publish a test message to the MQTT broker by using any MQTT client. For example, use mosquitto_pub:

mosquitto_pub -h $CLUSTER_HOST_IP -p 1883 -t "test/eventgrid" -m '{"temperature": 25.5}'

Then check the data flow is working:

1. Go to your Event Grid namespace in the Azure portal.

2. Check Metrics for incoming MQTT messages.

   

3. Verify the data flow pod logs show successful message delivery:

   kubectl logs -n azure-iot-operations -l app=dataflow --tail=50
   

If messages are flowing, the data flow is successfully routing through the private endpoint with managed identity auth. If messages don't arrive, see Data flow messages don't arrive at Event Grid.

After disabling public access on any Azure resource, verify Azure IoT Operations is still healthy. See Verify Azure IoT Operations health after lockdown.

Known limitations

• Platform validation: The private connectivity patterns described here are based on validated K3s on Ubuntu Server 24.04 scenarios. Other Kubernetes distributions or operating systems aren't independently validated.
• Schema registry RBAC: Use the --skip-ra flag during schema registry creation if you don't have owner-level permissions. Keep the trusted Azure services bypass (AzureServices) enabled in addition to the operations experience IP allow list so schema registry can access storage.
• TLS inspection: Arc Gateway doesn't support TLS termination or inspection. If your firewall performs TLS inspection, you must exclude the Arc Gateway endpoint from inspection. See Arc Gateway and TLS inspection.
• Arc Gateway limits: You can have up to five Arc Gateway resources per subscription.
• Explicit Proxy: Only Azure Firewall Explicit Proxy is validated. Third-party proxies (for example, Palo Alto) or transparent proxies aren't supported in validated scenarios. Azure IoT Operations doesn't support proxy servers that require a trusted certificate.

Related content

• Simplify network configuration requirements with Azure Arc Gateway
• Access Azure services over Azure Firewall Explicit Proxy
• Configure a data flow endpoint
• Schema Registry
• Tutorial: Deploy Azure IoT Operations in a layered network with private connectivity
• Azure IoT Operations networking
• Deploy Azure IoT Operations
• Azure Private DNS Zone values
• Troubleshoot private connectivity for Azure IoT Operations