Configure a private endpoint for an Azure Machine Learning workspace with SDK and CLI v1
APPLIES TO: Azure CLI ml extension v1 Python SDK azureml v1
In this document, you learn how to configure a private endpoint for your Azure Machine Learning workspace. For information on creating a virtual network for Azure Machine Learning, see Virtual network isolation and privacy overview.
Azure Private Link enables you to connect to your workspace using a private endpoint. The private endpoint is a set of private IP addresses within your virtual network. You can then limit access to your workspace to only occur over the private IP addresses. A private endpoint helps reduce the risk of data exfiltration. To learn more about private endpoints, see the Azure Private Link article.
Warning
Securing a workspace with private endpoints does not ensure end-to-end security by itself. You must secure all of the individual components of your solution. For example, if you use a private endpoint for the workspace, but your Azure Storage Account is not behind the VNet, traffic between the workspace and storage does not use the VNet for security.
For more information on securing resources used by Azure Machine Learning, see the following articles:
Prerequisites
- You must have an existing virtual network to create the private endpoint in.
- Disable network policies for private endpoints before adding the private endpoint.
Limitations
If you enable public access for a workspace secured with private endpoint and use Azure Machine Learning studio over the public internet, some features such as the designer may fail to access your data. This problem happens when the data is stored on a service that is secured behind the VNet. For example, an Azure Storage Account.
You may encounter problems trying to access the private endpoint for your workspace if you're using Mozilla Firefox. This problem may be related to DNS over HTTPS in Mozilla Firefox. We recommend using Microsoft Edge or Google Chrome as a workaround.
Using a private endpoint doesn't affect Azure control plane (management operations) such as deleting the workspace or managing compute resources. For example, creating, updating, or deleting a compute target. These operations are performed over the public Internet as normal. Data plane operations, such as using Azure Machine Learning studio, APIs (including published pipelines), or the SDK use the private endpoint.
When creating a compute instance or compute cluster in a workspace with a private endpoint, the compute instance and compute cluster must be in the same Azure region as the workspace.
When creating or attaching an Azure Kubernetes Service cluster to a workspace with a private endpoint, the cluster must be in the same region as the workspace.
When using a workspace with multiple private endpoints, one of the private endpoints must be in the same VNet as the following dependency services:
- Azure Storage Account that provides the default storage for the workspace
- Azure Key Vault for the workspace
- Azure Container Registry for the workspace.
For example, one VNet ('services' VNet) would contain a private endpoint for the dependency services and the workspace. This configuration allows the workspace to communicate with the services. Another VNet ('clients') might only contain a private endpoint for the workspace, and be used only for communication between client development machines and the workspace.
Create a workspace that uses a private endpoint
Use one of the following methods to create a workspace with a private endpoint. Each of these methods requires an existing virtual network:
Tip
If you'd like to create a workspace, private endpoint, and virtual network at the same time, see Use an Azure Resource Manager template to create a workspace for Azure Machine Learning.
The Azure Machine Learning Python SDK provides the PrivateEndpointConfig class, which can be used with Workspace.create() to create a workspace with a private endpoint. This class requires an existing virtual network.
APPLIES TO: Python SDK azureml v1
from azureml.core import Workspace
from azureml.core import PrivateEndPointConfig
pe = PrivateEndPointConfig(name='myprivateendpoint', vnet_name='myvnet', vnet_subnet_name='default')
ws = Workspace.create(name='myworkspace',
subscription_id='<my-subscription-id>',
resource_group='myresourcegroup',
location='eastus2',
private_endpoint_config=pe,
private_endpoint_auto_approval=True,
show_output=True)
Add a private endpoint to a workspace
Use one of the following methods to add a private endpoint to an existing workspace:
Warning
If you have any existing compute targets associated with this workspace, and they are not behind the same virtual network tha the private endpoint is created in, they will not work.
APPLIES TO: Python SDK azureml v1
from azureml.core import Workspace
from azureml.core import PrivateEndPointConfig
pe = PrivateEndPointConfig(name='myprivateendpoint', vnet_name='myvnet', vnet_subnet_name='default')
ws = Workspace.from_config()
ws.add_private_endpoint(private_endpoint_config=pe, private_endpoint_auto_approval=True, show_output=True)
For more information on the classes and methods used in this example, see PrivateEndpointConfig and Workspace.add_private_endpoint.
Remove a private endpoint
You can remove one or all private endpoints for a workspace. Removing a private endpoint removes the workspace from the VNet that the endpoint was associated with. Removing the private endpoint may prevent the workspace from accessing resources in that VNet, or resources in the VNet from accessing the workspace. For example, if the VNet doesn't allow access to or from the public internet.
Warning
Removing the private endpoints for a workspace doesn't make it publicly accessible. To make the workspace publicly accessible, use the steps in the Enable public access section.
To remove a private endpoint, use the following information:
To remove a private endpoint, use Workspace.delete_private_endpoint_connection. The following example demonstrates how to remove a private endpoint:
APPLIES TO: Python SDK azureml v1
from azureml.core import Workspace
ws = Workspace.from_config()
# get the connection name
_, _, connection_name = ws.get_details()['privateEndpointConnections'][0]['id'].rpartition('/')
ws.delete_private_endpoint_connection(private_endpoint_connection_name=connection_name)
Enable public access
In some situations, you may want to allow someone to connect to your secured workspace over a public endpoint, instead of through the VNet. Or you may want to remove the workspace from the VNet and re-enable public access.
Important
Enabling public access doesn't remove any private endpoints that exist. All communications between components behind the VNet that the private endpoint(s) connect to are still secured. It enables public access only to the workspace, in addition to the private access through any private endpoints.
Warning
When connecting over the public endpoint while the workspace uses a private endpoint to communicate with other resources:
- Some features of studio will fail to access your data. This problem happens when the data is stored on a service that is secured behind the VNet. For example, an Azure Storage Account.
- Using Jupyter, JupyterLab, RStudio, or Posit Workbench (formerly RStudio Workbench) on a compute instance, including running notebooks, is not supported.
To enable public access, use the following steps:
Tip
There are two possible properties that you can configure:
allow_public_access_when_behind_vnet
- used by the Python SDK and CLI v2public_network_access
- used by the Python SDK and CLI v2 Each property overrides the other. For example, settingpublic_network_access
will override any previous setting toallow_public_access_when_behind_vnet
.
Microsoft recommends using public_network_access
to enable or disable public access to a workspace.
To enable public access, use Workspace.update and set allow_public_access_when_behind_vnet=True
.
APPLIES TO: Python SDK azureml v1
from azureml.core import Workspace
ws = Workspace.from_config()
ws.update(allow_public_access_when_behind_vnet=True)
Securely connect to your workspace
To connect to a workspace that's secured behind a VNet, use one of the following methods:
Azure VPN gateway - Connects on-premises networks to the VNet over a private connection. Connection is made over the public internet. There are two types of VPN gateways that you might use:
- Point-to-site: Each client computer uses a VPN client to connect to the VNet.
- Site-to-site: A VPN device connects the VNet to your on-premises network.
ExpressRoute - Connects on-premises networks into the cloud over a private connection. Connection is made using a connectivity provider.
Azure Bastion - In this scenario, you create an Azure Virtual Machine (sometimes called a jump box) inside the VNet. You then connect to the VM using Azure Bastion. Bastion allows you to connect to the VM using either an RDP or SSH session from your local web browser. You then use the jump box as your development environment. Since it is inside the VNet, it can directly access the workspace. For an example of using a jump box, see Tutorial: Create a secure workspace.
Important
When using a VPN gateway or ExpressRoute, you will need to plan how name resolution works between your on-premises resources and those in the VNet. For more information, see Use a custom DNS server.
If you have problems connecting to the workspace, see Troubleshoot secure workspace connectivity.
Multiple private endpoints
Azure Machine Learning supports multiple private endpoints for a workspace. Multiple private endpoints are often used when you want to keep different environments separate. The following are some scenarios that are enabled by using multiple private endpoints:
Client development environments in a separate VNet.
An Azure Kubernetes Service (AKS) cluster in a separate VNet.
Other Azure services in a separate VNet. For example, Azure Synapse and Azure Data Factory can use a Microsoft managed virtual network. In either case, a private endpoint for the workspace can be added to the managed VNet used by those services. For more information on using a managed virtual network with these services, see the following articles:
Important
Synapse's data exfiltration protection is not supported with Azure Machine Learning.
Important
Each VNet that contains a private endpoint for the workspace must also be able to access the Azure Storage Account, Azure Key Vault, and Azure Container Registry used by the workspace. For example, you might create a private endpoint for the services in each VNet.
Adding multiple private endpoints uses the same steps as described in the Add a private endpoint to a workspace section.
Scenario: Isolated clients
If you want to isolate the development clients, so they don't have direct access to the compute resources used by Azure Machine Learning, use the following steps:
Note
These steps assume that you have an existing workspace, Azure Storage Account, Azure Key Vault, and Azure Container Registry. Each of these services has a private endpoints in an existing VNet.
- Create another VNet for the clients. This VNet might contain Azure Virtual Machines that act as your clients, or it may contain a VPN Gateway used by on-premises clients to connect to the VNet.
- Add a new private endpoint for the Azure Storage Account, Azure Key Vault, and Azure Container Registry used by your workspace. These private endpoints should exist in the client VNet.
- If you have another storage that is used by your workspace, add a new private endpoint for that storage. The private endpoint should exist in the client VNet and have private DNS zone integration enabled.
- Add a new private endpoint to your workspace. This private endpoint should exist in the client VNet and have private DNS zone integration enabled.
- Use the steps in the Use studio in a virtual network article to enable studio to access the storage account(s).
The following diagram illustrates this configuration. The Workload VNet contains computes created by the workspace for training & deployment. The Client VNet contains clients or client ExpressRoute/VPN connections. Both VNets contain private endpoints for the workspace, Azure Storage Account, Azure Key Vault, and Azure Container Registry.
Scenario: Isolated Azure Kubernetes Service
If you want to create an isolated Azure Kubernetes Service used by the workspace, use the following steps:
Note
These steps assume that you have an existing workspace, Azure Storage Account, Azure Key Vault, and Azure Container Registry. Each of these services has a private endpoints in an existing VNet.
- Create an Azure Kubernetes Service instance. During creation, AKS creates a VNet that contains the AKS cluster.
- Add a new private endpoint for the Azure Storage Account, Azure Key Vault, and Azure Container Registry used by your workspace. These private endpoints should exist in the client VNet.
- If you have other storage that is used by your workspace, add a new private endpoint for that storage. The private endpoint should exist in the client VNet and have private DNS zone integration enabled.
- Add a new private endpoint to your workspace. This private endpoint should exist in the client VNet and have private DNS zone integration enabled.
- Attach the AKS cluster to the Azure Machine Learning workspace. For more information, see Create and attach an Azure Kubernetes Service cluster.
Next steps
For more information on securing your Azure Machine Learning workspace, see the Virtual network isolation and privacy overview article.
If you plan on using a custom DNS solution in your virtual network, see how to use a workspace with a custom DNS server.