Publishing Azure Machine Learning Webservices the self-service way
Giving your data-analysts what they need with least privileges in Azure.
Problem description
Azure Machine Learning offers the possibility to publish predictive models as an Azure Machine Learning Webservice. These webservices can be used to make predictions based on new data. To publish Azure Machine Learning Webservices, according to the Microsoft documentation Contributor rights are needed. This contradicts with our company’s security policy: the Contributor role is able to create anything in your subscription and might cause a security breach. Since we are the infrastructure as code provider within our company we do not want that to happen.
Background
In our organization we have 3 departments that are involved in publishing web services:
Cloud Integration
- Creates a self-service capability to provision Azure Machine Learning workspaces via a CI/CD pipeline (VSTS)
Customer Data & Analytics
- Manage the workspaces: assign workspaces to the Data Analysts
- Create a Machine Learning Commitment Plan that is used to host the Azure Machine Learning Webservices
Data Analysts
- Create and refine the Machine Learning Models in their Machine Learning Workspace
- Publish the models as Azure Machine Learning Webservices to an existing Commitment Plan, using the Workspace option “Publish Webservice” which redirects
Solution
Authorizations in Azure are granted based upon Roles. These roles can be connect to AAD groups and users. There are no default Azure Roles available that can be used to assign the needed authorizations to only grant access to the resources that are needed to manage webservices and commitment plans. We have created new Custom Roles for the Data Tech Team and the Data Analysts.
This are the authorizations that we found out were needed for the Data Tech team:
- Microsoft.Resources/subscriptions/resourceGroups/read
- Microsoft.MachineLearning/commitmentPlans/*
- Microsoft.MachineLearning/Workspaces/read
- Microsoft.MachineLearning/webServices/read
- Microsoft.MachineLearning/Workspaces/listworkspacekeys/action
For the Data Analysts that need to publish the webservices we defined a Custom Role with the following access:
- Microsoft.Storage/storageAccounts/listkeys/action
- Microsoft.Resources/subscriptions/resourceGroups/read
- Microsoft.Storage/storageAccounts/read
- Microsoft.MachineLearning/webServices/*
- Microsoft.MachineLearning/commitmentPlans/read
- Microsoft.MachineLearning/commitmentPlans/commitmentAssociations/read
- Microsoft.MachineLearning/Workspaces/read
- Microsoft.MachineLearning/Workspaces/write
- Microsoft.MachineLearning/Workspaces/listworkspacekeys/action
We assign the custom roles on resourcegroup level, and link the user (via Azure Active Directory groups) to the roles. This way we are sure that the right people can deploy the Commitmentplans and the Azure Machine Learning Webservices only, so we stay in control of what is deployed to our Azure subscriptions.
One caveat: the CommitmentPlan can be deployed to a separate resourcegroup, but you cannot choose the resourcegroup where the WebServices are deployed. They are deployed to the resourcegroup where the Machine Learning Workspace resides.
How did we do it
We had to find out with trial and error what authorizations were needed. We used one of the sample experiments to publish a webservice via Machine Learning Studio workspace, and checked the event logging in ARM to see in what stage the deployment failed.
We saw no error in the ARM logging when we deployed a web services using a user with insufficient authorizations at first. But after granting more permissions on the resource group level we could at least see what authorizations were needed to deploy the webservices. The Microsoft.Storage/storageAccounts/listkeys/action authorization was essential: after we had granted our test user this access we could further pinpoint which other resources were accessed.
