2.4 Configure Identity and Access Management for Workspaces

Configure Identity and Access Management for Workspaces

Quick Answer: Use Azure RBAC. AzureML Data Scientist runs jobs but cannot create compute or change the workspace. AzureML Compute Operator creates compute. Combine those two for self-serve scientists. Put roles on Microsoft Entra groups. Use managed identities for Storage, Key Vault, and ACR. Do not paste keys into notebooks.

Identity for Azure Machine Learning is the same Azure role-based access control (Azure RBAC) you use on any Azure resource, plus managed identities and service principals for non-human access. There is no separate “studio password file.” If a user’s role cannot create a compute instance, studio hides the create button. That is expected, not a studio bug.

This section is workspace IAM for classic Azure Machine Learning (Domain 1). Microsoft Foundry has its own IAM bullets in Domain 3; the products share hub resource types and Entra, but you should answer Domain 1 items with the Azure Machine Learning built-in roles below.

Built-in roles you must be able to name

AzureML Registry User is not a workspace role. Assign it on an Azure Machine Learning registry so data scientists can read and write assets in the registry without being able to create or delete the registry resource. Admins still use Contributor or Owner on the registry itself.

The combination the exam wants for “scientists who can train and spin up a cluster, but must not own the workspace” is AzureML Data Scientist + AzureML Compute Operator. Contributor also works but is broader than least privilege. Owner is how you accidentally let a contractor reassign RBAC.

Role scope matters. Owner on the workspace is not automatically Owner on the resource group. Quota operations for managed compute require permission at subscription scope (/locations/updateQuotas/action). A workspace Owner who cannot raise GPU quota is not a contradiction.

Custom roles are available when the built-ins are wrong. A typical custom data-scientist definition allows Microsoft.MachineLearningServices/workspaces/* except workspace write/delete, compute write/delete, and Microsoft.Authorization/*/write. Include both v1 and v2 action paths if you still have mixed clients (workspaces/jobs/* and workspaces/experiments/*, workspaces/components/* and workspaces/modules/*). Role assignment changes can take up to an hour to appear because of permission caching.

Microsoft Entra groups, not one row per user

Assign AzureML Data Scientist (and Compute Operator, if needed) to a Microsoft Entra security group such as sg-ml-claims-scientists. Then:

• The group owner can add and remove members without being Owner on the workspace.
• Offboarding is one group removal, and it also revokes whatever other Azure resources used the same group.
• You are less likely to hit the subscription role-assignment limit.

This is the same pattern section 2.1 recommended for workspace organization. On a hub, also remember Microsoft.MachineLearningServices/workspaces/hubs/join/action for people who create project workspaces; Azure AI Developer is a built-in that includes it.

Managed identities: workspace, compute, and jobs

A managed identity is an Entra identity whose password Azure rotates. You do not put that password in a notebook.

Workspace identity

• Default: system-assigned (lifecycle tied to the workspace; principal ID is the workspace).
• Optional: user-assigned, or system-assigned plus user-assigned. After you move a workspace to system+user-assigned, you cannot go back to system-assigned only.
• The workspace identity talks to Storage, Key Vault, ACR, and other Azure services on the workspace’s behalf (including some studio data previews).

Workspaces created after 19 November 2024 grant the system-assigned identity Azure AI Administrator on the resource group—narrower than the old Contributor grant. Older workspaces can be converted with az ml workspace update --allow-roleassignment-on-rg true (CLI v2.27.0+) or the SDK allow_roleassignment_on_rg = True. Do not revert to Contributor unless you are hitting a real product bug; if you must, file a support case.

When you bring a user-assigned identity to the workspace, that identity needs control-plane and often data-plane roles on the associated resources: Contributor on the workspace, Storage Blob Data Contributor (for studio preview), Key Vault Administrator or access policies (except purge), Contributor on ACR, Contributor on Application Insights. Multiple user-assigned identities are allowed; you pick a primary one.

Compute identity

• Clusters: one system-assigned or multiple user-assigned, not both.
• Kubernetes compute: one system-assigned or one user-assigned, not both.
• The default identity mounts datastores and pulls images. Grant it AcrPull on ACR and Storage Blob Data Reader (or more) on data accounts.
• If you create the cluster before the workspace ACR exists, AcrPull is not automatic—assign it yourself after ACR appears.
• Compute-instance idle shutdown with a managed identity requires that identity to have Contributor on the workspace, or idle shutdown will not stop the VM.

Job identity

• Default on many cluster jobs: the compute managed identity.
• UserIdentityConfiguration / identity: type: user_identity: the submitting user’s token (CLI/SDK v2; fine-grained storage ACLs; checksum validation may require re-uploading old components).
• Serverless: user identity or workspace user-assigned identity. No system-assigned identity on the serverless job.
• Online endpoint identity is set at create and is immutable.

Service principals are app registrations you create for GitHub Actions, Azure DevOps, or other automation that is not a managed identity. Grant the principal the same least-privilege workspace role you would grant a human (often a custom MLOps role that can submit jobs and read datastores, not Owner). Prefer federated credentials (workload identity) from GitHub to the app registration so you are not storing a client secret in GitHub either. Chapter 4 covers wiring that into Bicep and Actions; the IAM rule is that the pipeline identity is just another Entra principal with RBAC.

Keys, ACR admin, and the anti-pattern the exam is fishing for

If a notebook says AccountKey=... or reads list_keys into an environment variable, mark it wrong whenever a managed identity is available. Concrete replacements:

• Identity-based datastore + compute managed identity + Storage Blob Data Reader
• ManagedIdentityCredential(client_id=os.environ["DEFAULT_IDENTITY_CLIENT_ID"]) inside cluster job code
• ACR with admin user disabled, cluster identity AcrPull, workspace identity for image build

Auto-created ACR enables the admin account. Disable it (az acr update --admin-enabled false) after the first image build, or bring an ACR that never had admin enabled and pass its resource ID into az ml workspace create --container-registry.

Reader can view datastore credentials. That is why credential-based datastores plus a wide Reader assignment leak keys. Identity-based datastores store no key to leak.

Practical assignment workflow

Owners (or users with Microsoft.Authorization/roleAssignments/write at the right scope) assign roles in the Azure portal, Azure CLI, PowerShell, REST, or ARM/Bicep. Example:

az role assignment create \
  --role "AzureML Data Scientist" \
  --assignee-object-id <entra-group-object-id> \
  --assignee-principal-type Group \
  --scope /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.MachineLearningServices/workspaces/<workspace>

Repeat for AzureML Compute Operator on the same group if those users must create compute. Repeat on the registry with AzureML Registry User if they consume shared environments from a registry rather than from the workspace alone.

Conflicting role assignments are additive: an Action in one role can override a NotAction in another. If someone “still can delete compute” after you apply a locked-down custom role, look for a second Contributor assignment inherited from the resource group.

Creating the first workspace in a subscription also requires Microsoft.MachineLearningServices/register/action so the resource provider can register. Missing that permission looks like a mysterious ARM failure, not an ML error.

Exam scenario

You have 40 data scientists, two platform engineers, and a GitHub Actions workflow that submits nightly training. Put the scientists in an Entra group with AzureML Data Scientist. Add AzureML Compute Operator only if they must create instances; otherwise the platform team owns compute. Platform engineers get Contributor or Owner on the workspace (Owner if they assign roles). The Actions workflow uses a service principal or federated-credential app with a job-submit custom role. The cluster’s system-assigned identity has Storage Blob Data Reader and AcrPull. Nobody pastes a storage key into a notebook.

Common trap

Granting Contributor on the storage account and assuming blob reads work—data-plane Storage Blob Data Reader is still required for identity-based access. The sibling trap is assigning only AzureML Data Scientist and then wondering why studio will not create a compute instance: that role is designed to block compute create. A third trap is using Reader for “safe visibility” on a workspace that has credential-based datastores; Reader can still see those credentials.