This is a continuation of a series of articles on IaC shortcomings and resolutions. The resource type discussed was azure machine learning workspace. An Azure Machine Learning Workspace is a cloud-based environment provided by Microsoft Azure that enables data scientists and machine learning engineers to build, train, deploy, and manage machine learning models. It provides a collaborative space where teams can work together on machine learning projects, and it offers a range of tools and services to support the end-to-end machine learning lifecycle.

Within an Azure Machine Learning Workspace, you can access and manage data, create and run experiments, track and version models, and deploy models as web services or containers. It also integrates with other Azure services, such as Azure Databricks, Azure Notebooks, and Azure DevOps, to provide a comprehensive ecosystem for machine learning development and deployment.

The Azure Machine Learning Workspace simplifies many common tasks in the machine learning workflow, such as data preparation, feature engineering, model training, and model deployment. It also provides scalability and flexibility, allowing you to leverage the power of the cloud to handle large datasets and complex machine learning scenarios.

Many workspaces are deployed with public IP networking enabled because it grants connectivity to all other resources directly from the code in the notebook. On the other hand, enterprises like to lock down access to restricted resources and targets by allowing only select source-destination traffic. When the IP networking is enabled on the workspace, all the compute instances created in the workspace get public IP connectivity by virtue of the workspace’s public IP address even if these instances do not get a public IP address themselves. The notebook can access dependencies of the workspace such as storage account, key vault, container registry and application insights over the public network. When a virtual network is provided for the instances to be associated with a subnet, then that subnet must be allowed on the dependencies networking. Additionally, private or service endpoints must be added for these dependencies. The IaC for deployment of these dependencies can order them before the main workspace but role-based access control must be specifically added afterwards.

One of the least anticipated problems is when the workspace is converted from public to private networking. In this case, there are three error types encountered for the nominal change in the IaC to turn off the public networking enabled boolean. These are 1. additional policy compliance, 2. Allowlisting of the workspace’s identity on control and data plane for the dependencies and 3. Enabling a designated image build compute on the workspace. While the original deployment IaC does not call these out, these changes must also be made in the code before taking the workspace private. Previous article: IaCResolutionsPart91.docx