Edit

Share via

How to configure a private link for Azure AI Foundry

When using a Foundry project, you can use a private link to secure communication with your project. This article describes how to establish a private connection to your project using a private link.

When using a hub based project, there are two network isolation aspects to consider:

  • Network isolation to access an Azure AI Foundry hub: This is the focus of this article. It describes how to establish a private connection to your hub and its default resources using a private link.
  • Network isolation of computing resources in your hub and projects: This includes compute instances, serverless, and managed online endpoints. For more information, see the Configure managed networks for Azure AI Foundry hubs article.

Diagram of Azure AI Foundry hub network isolation.

You get several hub default resources in your resource group. You need to configure following network isolation configurations:

  • Disable public network access of hub default resources such as Azure Storage, Azure Key Vault, and Azure Container Registry.
  • Establish private endpoint connection to hub default resources. You need to have both a blob and file private endpoint for the default storage account.
  • If your storage account is private, assign roles to allow access.

Prerequisites

  • You must have an existing Azure Virtual Network to create the private endpoint in.

    Important

    We don't recommend using the 172.17.0.0/16 IP address range for your VNet. This is the default subnet range used by the Docker bridge network on-premises.

  • Disable network policies for private endpoints before adding the private endpoint.

Create a Foundry project that uses a private endpoint

When creating a new project, use the following steps to create the project.

  1. From the Azure portal, search for Azure AI Foundry and select Create a resource.

  2. After configuring the Basics tab, select the Networking tab and then the Disabled option.

  3. From the Private endpoint section, select + Add private endpoint.

  4. When going through the forms to create a private endpoint, be sure to:

    • From Basics, select the same Region as your virtual network.
    • From the Virtual Network form, select the virtual network and subnet that you want to connect to.

  5. Continue through the forms to create the project. When you reach the Review + create tab, review your settings and select Create to create the project.

Create a hub that uses a private endpoint

If you're creating a new hub, use the following methods to create the hub (Azure portal or Azure CLI). Each of these methods requires an existing virtual network:

Note

The information in this document is only about configuring a private link. For a walkthrough of creating a secure hub in the portal, see Create a secure hub in the Azure portal.

  1. From the Azure portal, search for Azure AI Foundry. From the left menu, select AI Hubs, and then select + Create and Hub.

    Screenshot of the Azure AI Foundry portal.

  2. After configuring the Basics and Storage tabs, select the Inbound access tab and then select + Add. When prompted, enter the data for the Azure Virtual Network and subnet for the private endpoint. When selecting the Region, select the same region as your virtual network.

    Screenshot of the inbound access tab with public network access disabled.

  3. Select the Outbound access tab and pick the Network isolation option that best suits your needs.

    Screenshot of the Create a hub with the option to set network isolation information.

Add a private endpoint to a project

  1. From the Azure portal, select your project.

  2. From the left side of the page, select Resource Management, Networking, and then select the Private endpoint connections tab. Select + Private endpoint.

  3. When going through the forms to create a private endpoint, be sure to:

    • From Basics, select the same Region as your virtual network.
    • From the Virtual Network form, select the virtual network and subnet that you want to connect to.

  4. After populating the forms with any other network configurations you require, use the Review + create tab to review your settings and select Create to create the private endpoint.

Add a private endpoint to a hub

Use one of the following methods to add a private endpoint to an existing hub:

  1. From the Azure portal, select your hub.

  2. From the left side of the page, select Settings, Networking, and then select the Private endpoint connections tab. Select + Private endpoint.

    Screenshot of the private endpoint connections tab

  3. When going through the forms to create a private endpoint, be sure to:

    • From Basics, select the same Region as your virtual network.
    • From Resource, select amlworkspace as the target sub-resource.
    • From the Virtual Network form, select the virtual network and subnet that you want to connect to.

  4. After populating the forms with any other network configurations you require, use the Review + create tab to review your settings and select Create to create the private endpoint.

Remove a private endpoint from a project

You can remove one or all private endpoints for a project. Removing a private endpoint removes the project from the Azure Virtual Network that the endpoint was associated with. Removing the private endpoint might prevent the project from accessing resources in that virtual network, or resources in the virtual network from accessing the workspace. For example, if the virtual network doesn't allow access to or from the public internet.

Warning

Removing the private endpoints for a project doesn't make it publicly accessible. To make the project publicly accessible, use the steps in the Enable public access section.

To remove a private endpoint, use the following information:

  1. From the Azure portal, select your project.
  2. From the left side of the page, select Resource Management, Networking, and then select the Private endpoint connections tab.
  3. Select the endpoint to remove and then select Remove.

Remove a private endpoint

You can remove one or all private endpoints for a hub. Removing a private endpoint removes the hub from the Azure Virtual Network that the endpoint was associated with. Removing the private endpoint might prevent the hub from accessing resources in that virtual network, or resources in the virtual network from accessing the workspace. For example, if the virtual network doesn't allow access to or from the public internet.

Warning

Removing the private endpoints for a hub doesn't make it publicly accessible. To make the hub publicly accessible, use the steps in the Enable public access section.

To remove a private endpoint, use the following information:

  1. From the Azure portal, select your hub.

  2. From the left side of the page, select Settings, Networking, and then select the Private endpoint connections tab.

  3. Select the endpoint to remove and then select Remove.

    Screenshot of a selected private endpoint with the remove option highlighted.

Enable public access

In some situations, you might want to allow someone to connect to your secured project over a public endpoint, instead of through the virtual network. Or you might want to remove the project from the virtual network and re-enable public access.

Important

Enabling public access doesn't remove any private endpoints that exist. All communications between components behind the virtual network that the private endpoint(s) connect to are still secured. It enables public access only to the project, in addition to the private access through any private endpoints.

  1. From the Azure portal, select your project.

  2. From the left side of the page, select Resource Management, Networking, and then select the Firewalls and virtual networks tab.

  3. Select All networks, and then select Save.

    Screenshot of the firewalls and virtual networks tab with the all networks option selected.

Enable public access

In some situations, you might want to allow someone to connect to your secured hub over a public endpoint, instead of through the virtual network. Or you might want to remove the workspace from the virtual network and re-enable public access.

Important

Enabling public access doesn't remove any private endpoints that exist. All communications between components behind the virtual network that the private endpoint(s) connect to are still secured. It enables public access only to the hub, in addition to the private access through any private endpoints.

To enable public access, use the following steps:

  1. From the Azure portal, select your hub.
  2. From the left side of the page, select Networking and then select the Public access tab.
  3. Select Enabled from all networks, and then select Save.

Enable Public Access only from internet IP ranges (preview)

You can use IP network rules to allow access to your secured hub from specific public internet IP address ranges by creating IP network rules. Each Azure AI Foundry hub supports up to 200 rules. These rules grant access to specific internet-based services and on-premises networks and block general internet traffic. This feature is currently in preview.

Warning

  • Enable your endpoint's public network access flag if you want to allow access to your endpoint from specific public internet IP address ranges.
  • You can only use IPv4 addresses.
  • If the workspace goes from Enable from selected IPs to Disabled or Enabled, the IP ranges are reset.
  1. From the Azure portal, select your Azure Machine AI Foundry hub.
  2. From the left side of the page, select Networking and then select the Public access tab.
  3. Select Enabled from selected IP addresses, input address ranges and then select Save.

You can also use the Workspace class from the Azure Machine Learning Python SDK to define which IP addresses are allowed inbound access:

class Workspace(Resource):
    """Azure ML workspace.
    :param public_network_access: Whether to allow public endpoint connectivity
        when a workspace is private link enabled.
    :type public_network_access: str
    :param network_acls: The network access control list (ACL) settings of the workspace.
    :type network_acls: ~azure.ai.ml.entities.NetworkAcls

    def __init__(
        self,
        *,
        public_network_access: Optional[str] = None,
        network_acls: Optional[NetworkAcls] = None,

Restrictions for IP network rules

The following restrictions apply to IP address ranges:

  • IP network rules are allowed only for public internet IP addresses.

    Reserved IP address ranges aren't allowed in IP rules such as private addresses that start with 10, 172.16 to 172.31, and 192.168.

  • You must provide allowed internet address ranges by using CIDR notation in the form 16.17.18.0/24 or as individual IP addresses like 16.17.18.19.

  • Only IPv4 addresses are supported for configuration of storage firewall rules.

  • When this feature is enabled, you can test public endpoints using any client tool such as Curl, but the Endpoint Test tool in the portal isn't supported.

  • You can only set the IP addresses for the AI Foundry hub after the hub is created.

Private storage configuration

If your storage account is private (uses a private endpoint to communicate with your project), you perform the following steps:

  1. Our services need to read/write data in your private storage account using Allow Azure services on the trusted services list to access this storage account with following managed identity configurations. Enable the system assigned managed identity of Azure AI Service and Azure AI Search, then configure role-based access control for each managed identity.

    Role Managed Identity Resource Purpose Reference
    Reader Azure AI Foundry project Private endpoint of the storage account Read data from the private storage account.
    Storage File Data Privileged Contributor Azure AI Foundry project Storage Account Read/Write prompt flow data. Prompt flow doc
    Storage Blob Data Contributor Azure AI Service Storage Account Read from input container, write to preprocess result to output container. Azure OpenAI Doc
    Storage Blob Data Contributor Azure AI Search Storage Account Read blob and write knowledge store Search doc.

    Tip

    Your storage account might have multiple private endpoints. You need to assign the Reader role to each private endpoint for your Azure AI Foundry project managed identity.

  2. Assign the Storage Blob Data reader role to your developers. This role allows them to read data from the storage account.

  3. Verify that the project's connection to the storage account uses Microsoft Entra ID for authentication. To view the connection information, go to the Management center, select Connected resources, and then select the storage account connections. If the credential type isn't Entra ID, select the pencil icon to update the connection and set the Authentication method to Microsoft Entra ID.

For information on securing playground chat, see Securely use playground chat.

End-to-end secured networking for Agent Service

When creating a Foundry resource and Foundry project to build Agents, we recommend the following network architecture for the most secure end-to-end configuration:

Diagram of the recommended network isolation for AI Foundry projects and agents.

  1. Set the public network access (PNA) flag of each of your resources to Disabled. Disabling public network access locks down inbound access from the public internet to the resources.

  2. Create a private endpoint for each of your Azure resources that are required for a Standard Agent:

    • Azure Storage Account
    • Azure AI Search resource
    • Cosmos DB resource
    • Azure AI Foundry resource

  3. To access your resources, we recommend using a Bastion VM, ExpressRoute, or VPN connection to your Azure Virtual Network. These options allow you to connect to the isolated network environment.

Network injection for Agent Service

Network-secured Standard Agents support full network isolation and data exfiltration protection through network injection of the Agent client. To do this, the Agent client is network injected into your Azure virtual network, allowing for strict control over data movement and preventing data exfiltration by keeping traffic within your defined network boundaries. Network injection is supported only for Standard Agent deployment, not Light Agent deployment.

Additionally, a network-secured Standard Agent is only supported through BICEP template deployment, and not through UX, CLI, or SDK. After the Foundry resource and Agent are deployed through the template, you can't update the delegated subnet for the Agent Service. This is visible in the Foundry resource Networking tab, where you can view and copy the subnet, but can't update or remove the subnet delegation. To update the delegated subnet, you must redeploy the network-secured Standard Agent template.

Diagram of the network injection for Azure AI Foundry projects and agents.

For more information on secured networking for the Agent Service, see How to use a virtual network with the Azure AI Agent Service article.

DNS configuration

Clients on a virtual network that use the private endpoint use the same connection string for the Azure AI Foundry resource and projects as clients connecting to the public endpoint. DNS resolution automatically routes the connections from the virtual network to the Azure AI Foundry resource and projects over a private link.

Apply DNS changes for private endpoints

When you create a private endpoint, the DNS CNAME resource record for the Azure AI Foundry resource is updated to an alias in a subdomain with the prefix privatelink. By default, Azure also creates a private DNS zone that corresponds to the privatelink subdomain, with the DNS A resource records for the private endpoints. For more information, see what is Azure Private DNS.

When you resolve the endpoint URL from outside the virtual network with the private endpoint, it resolves to the public endpoint of the Azure AI Foundry resource. When it's resolved from the virtual network hosting the private endpoint, it resolves to the private IP address of the private endpoint.

This approach enables access to the Azure AI Foundry resource using the same connection string for clients in the virtual network that hosts the private endpoints, and clients outside the virtual network.

If you use a custom DNS server on your network, clients must be able to resolve the fully qualified ___domain name (FQDN) for the Azure AI services resource endpoint to the private endpoint IP address. Configure your DNS server to delegate your private link subdomain to the private DNS zone for the virtual network.

Tip

When you use a custom or on-premises DNS server, you should configure your DNS server to resolve the Azure AI services resource name in the privatelink subdomain to the private endpoint IP address. Delegate the privatelink subdomain to the private DNS zone of the virtual network. Alternatively, configure the DNS zone of your DNS server and add the DNS A records.

For more information on configuring your own DNS server to support private endpoints, use the following articles:

Grant access to trusted Azure services

You can grant a subset of trusted Azure services access to Azure OpenAI, while maintaining network rules for other apps. These trusted services then use managed identity to authenticate your Azure OpenAI resources. The following table lists the services that can access Azure OpenAI if the managed identity of those services has the appropriate role assignment:

Service Resource provider name
Azure AI Search Microsoft.Search

You can grant networking access to trusted Azure services by creating a network rule exception using the REST API or Azure portal.

See Azure Machine Learning custom DNS article for the DNS forwarding configurations.

If you need to configure custom DNS server without DNS forwarding, use the following patterns for the required A records.

  • <AI-HUB-GUID>.workspace.<region>.cert.api.azureml.ms

  • <AI-HUB-GUID>.workspace.<region>.api.azureml.ms

  • ml-<workspace-name, truncated>-<region>-<AI-HUB-GUID>.<region>.notebooks.azure.net

    Note

    The workspace name for this FQDN might be truncated. Truncation is done to keep ml-<workspace-name, truncated>-<region>-<workspace-guid> at 63 characters or less.

  • <instance-name>.<region>.instances.azureml.ms

    Note

    • Compute instances can be accessed only from within the virtual network.
    • The IP address for this FQDN is not the IP of the compute instance. Instead, use the private IP address of the workspace private endpoint (the IP of the *.api.azureml.ms entries.)

  • <instance-name>-22.<region>.instances.azureml.ms - Only used by the az ml compute connect-ssh command to connect to computers in a managed virtual network. Not needed if you aren't using a managed network or SSH connections.

  • <managed online endpoint name>.<region>.inference.ml.azure.com - Used by managed online endpoints

  • models.ai.azure.com - Used for standard deployment

To find the private IP addresses for your A records, see the Azure Machine Learning custom DNS article.

Note

Project workspaces reuse the FQDNs of the associated hub workspaces. There's no reason to configure separate entries for the project workspace GUIDs.

Limitations

  • You might encounter problems trying to access the private endpoint for your hub if you're using Mozilla Firefox. This problem might be related to DNS over HTTPS in Mozilla Firefox. We recommend using Microsoft Edge or Google Chrome.
  • A network-secured Agent (bring your own virtual network) is only supported through Bicep template deployment. For more information on network-secured Agent deployment, see How to use a virtual network with the Azure AI Agent Service.
  • A network-secured Agent to be deployed is only a Standard Agent, not a Light Agent.
  • There's no managed virtual network support for the Agent Service or Foundry project.

Next steps