Secure Azure Machine Learning workspace resources using virtual networks (SDK/CLI v1)

APPLIES TO: Python SDK azureml v1

APPLIES TO: Azure CLI ml extension v1

Secure Azure Machine Learning workspace resources and compute environments using virtual networks (VNets). This article uses an example scenario to show you how to configure a complete virtual network.

Prerequisites

This article assumes that you have familiarity with the following topics:

• Azure Virtual Networks
• IP networking
• Azure Machine Learning workspace with private endpoint
• Network Security Groups (NSG)
• Network firewalls

Example scenario

In this section, you learn how a common network scenario is set up to secure Azure Machine Learning communication with private IP addresses.

The following table compares how services access different parts of an Azure Machine Learning network with and without a VNet:

Scenario	Workspace	Associated resources	Training compute environment	Inferencing compute environment
No virtual network	Public IP	Public IP	Public IP	Public IP
Public workspace, all other resources in a virtual network	Public IP	Public IP (service endpoint) - or - Private IP (private endpoint)	Public IP	Private IP
Secure resources in a virtual network	Private IP (private endpoint)	Public IP (service endpoint) - or - Private IP (private endpoint)	Private IP	Private IP

• Workspace - Create a private endpoint for your workspace. The private endpoint connects the workspace to the vnet through several private IP addresses.
  • Public access - You can optionally enable public access for a secured workspace.
• Associated resource - Use service endpoints or private endpoints to connect to workspace resources like Azure storage, Azure Key Vault. For Azure Container Services, use a private endpoint.
  • Service endpoints provide the identity of your virtual network to the Azure service. Once you enable service endpoints in your virtual network, you can add a virtual network rule to secure the Azure service resources to your virtual network. Service endpoints use public IP addresses.
  • Private endpoints are network interfaces that securely connect you to a service powered by Azure Private Link. Private endpoint uses a private IP address from your VNet, effectively bringing the service into your VNet.
• Training compute access - Access training compute targets like Azure Machine Learning Compute Instance and Azure Machine Learning Compute Clusters with public or private IP addresses.
• Inference compute access - Access Azure Kubernetes Services (AKS) compute clusters with private IP addresses.

The next sections show you how to secure the network scenario described above. To secure your network, you must:

1. Secure the workspace and associated resources.
2. Secure the training environment (v1).
3. Secure the inferencing environment (v1).
4. Optionally: enable studio functionality.
5. Configure firewall settings.
6. Configure DNS name resolution.

Public workspace and secured resources

If you want to access the workspace over the public internet while keeping all the associated resources secured in a virtual network, use the following steps:

1. Create an Azure Virtual Network that will contain the resources used by the workspace.

2. Use one of the following options to create a publicly accessible workspace:

   • Create an Azure Machine Learning workspace that does not use the virtual network. For more information, see Manage Azure Machine Learning workspaces.
   • Create a Private Link-enabled workspace to enable communication between your VNet and workspace. Then enable public access to the workspace.

3. Add the following services to the virtual network by using either a service endpoint or a private endpoint. Also allow trusted Azure services to access these services:

   Service	Endpoint information	Allow trusted information
   Azure Key Vault	Service endpoint Private endpoint	Allow trusted Azure services to bypass this firewall
   Azure Storage Account	Service and private endpoint Private endpoint	Grant access to trusted Azure services
   Azure Container Registry	Private endpoint	Allow trusted services

4. In properties for the Azure Storage Account(s) for your workspace, add your client IP address to the allowed list in firewall settings. For more information, see Configure firewalls and virtual networks.

Secure the workspace and associated resources

Use the following steps to secure your workspace and associated resources. These steps allow your services to communicate in the virtual network.

1. Create an Azure Virtual Networks that will contain the workspace and other resources. Then create a Private Link-enabled workspace to enable communication between your VNet and workspace.

2. Add the following services to the virtual network by using either a service endpoint or a private endpoint. Also allow trusted Azure services to access these services:

   Service	Endpoint information	Allow trusted information
   Azure Key Vault	Service endpoint Private endpoint	Allow trusted Azure services to bypass this firewall
   Azure Storage Account	Service and private endpoint Private endpoint	Grant access from Azure resource instances or Grant access to trusted Azure services
   Azure Container Registry	Private endpoint	Allow trusted services

For detailed instructions on how to complete these steps, see Secure an Azure Machine Learning workspace.

Limitations

Securing your workspace and associated resources within a virtual network have the following limitations:

• All resources must be behind the same VNet. However, subnets within the same VNet are allowed.

Secure the training environment

In this section, you learn how to secure the training environment in Azure Machine Learning. You also learn how Azure Machine Learning completes a training job to understand how the network configurations work together.

To secure the training environment, use the following steps:

1. Create an Azure Machine Learning compute instance and computer cluster in the virtual network to run the training job.

2. If your compute cluster or compute instance uses a public IP address, you must Allow inbound communication so that management services can submit jobs to your compute resources.

   Tip

   Compute cluster and compute instance can be created with or without a public IP address. If created with a public IP address, you get a load balancer with a public IP to accept the inbound access from Azure batch service and Azure Machine Learning service. You need to configure User Defined Routing (UDR) if you use a firewall. If created without a public IP, you get a private link service to accept the inbound access from Azure batch service and Azure Machine Learning service without a public IP.

For detailed instructions on how to complete these steps, see Secure a training environment.

Example training job submission

In this section, you learn how Azure Machine Learning securely communicates between services to submit a training job. This shows you how all your configurations work together to secure communication.

1. The client uploads training scripts and training data to storage accounts that are secured with a service or private endpoint.

2. The client submits a training job to the Azure Machine Learning workspace through the private endpoint.

3. Azure Batch service receives the job from the workspace. It then submits the training job to the compute environment through the public load balancer for the compute resource.

4. The compute resource receives the job and begins training. The compute resource uses information stored in key vault to access storage accounts to download training files and upload output.

Limitations

• Azure Compute Instance and Azure Compute Clusters must be in the same VNet, region, and subscription as the workspace and its associated resources.

Secure the inferencing environment (v1)

APPLIES TO: Python SDK azureml v1

APPLIES TO: Azure CLI ml extension v1

In this section, you learn the options available for securing an inferencing environment when using the Azure CLI extension for ML v1 or the Azure Machine Learning Python SDK v1. When doing a v1 deployment, we recommend that you use Azure Kubernetes Services (AKS) clusters for high-scale, production deployments.

You have two options for AKS clusters in a virtual network:

• Deploy or attach a default AKS cluster to your VNet.
• Attach a private AKS cluster to your VNet.

Default AKS clusters have a control plane with public IP addresses. You can add a default AKS cluster to your VNet during the deployment or attach a cluster after it's created.

Private AKS clusters have a control plane, which can only be accessed through private IPs. Private AKS clusters must be attached after the cluster is created.

For detailed instructions on how to add default and private clusters, see Secure an inferencing environment.

Regardless default AKS cluster or private AKS cluster used, if your AKS cluster is behind of VNET, your workspace and its associate resources (storage, key vault, and ACR) must have private endpoints or service endpoints in the same VNET as the AKS cluster.

The following network diagram shows a secured Azure Machine Learning workspace with a private AKS cluster attached to the virtual network.

Optional: Enable public access

You can secure the workspace behind a VNet using a private endpoint and still allow access over the public internet. The initial configuration is the same as securing the workspace and associated resources.

After securing the workspace with a private endpoint, use the following steps to enable clients to develop remotely using either the SDK or Azure Machine Learning studio:

1. Enable public access to the workspace.
2. Configure the Azure Storage firewall to allow communication with the IP address of clients that connect over the public internet.

Optional: Enable studio functionality

If your storage is in a VNet, you must use extra configuration steps to enable full functionality in studio. By default, the following features are disabled:

• Preview data in the studio.
• Visualize data in the designer.
• Deploy a model in the designer.
• Submit an AutoML experiment.
• Start a labeling project.

To enable full studio functionality, see Use Azure Machine Learning studio in a virtual network.

Limitations

ML-assisted data labeling doesn't support a default storage account behind a virtual network. Instead, use a storage account other than the default for ML assisted data labeling.

Configure firewall settings

Configure your firewall to control traffic between your Azure Machine Learning workspace resources and the public internet. While we recommend Azure Firewall, you can use other firewall products.

For more information on firewall settings, see Use workspace behind a Firewall.

Custom DNS

If you need to use a custom DNS solution for your virtual network, you must add host records for your workspace.

For more information on the required domain names and IP addresses, see how to use a workspace with a custom DNS server.

Public access

Azure Sentinel can automatically create a workspace for you if you are OK with a public endpoint. In this configuration, the security operations center (SOC) analysts and system administrators connect to notebooks in your workspace through Sentinel.

Private endpoint

If you want to secure your workspace and associated resources in a VNet, you must create the Azure Machine Learning workspace first. You must also create a virtual machine 'jump box' in the same VNet as your workspace, and enable Azure Bastion connectivity to it. Similar to the public configuration, SOC analysts and administrators can connect using Azure Sentinel, but some operations must be performed using Azure Bastion to connect to the VM.

Next steps

This article is part of a series on securing an Azure Machine Learning workflow. See the other articles in this series:

• Secure the workspace resources
• Secure the training environment (v1)
• Secure inference environment (v1)
• Enable studio functionality
• Use custom DNS
• Use a firewall
• API platform network isolation