Cloud Security Wire
AWS Azure GCP RSS
Azure Misconfiguration high

Azure Machine Learning Workspace Security: Credential Theft, RBAC Abuse, and Hardening

Azure ML workspaces grant Jupyter notebooks, compute clusters, and pipelines access to storage, secrets, and sometimes subscription-level IAM. This guide covers the most dangerous misconfiguration patterns and how to lock them down.

By Editorial Team · ·
#azure#machine-learning#azure-ml#managed-identity#credential-theft#rbac#jupyter#compute-cluster#key-vault#mlops
High Severity

This issue has been assessed as high severity. Review affected configurations immediately.

Azure Machine Learning workspaces are a common blind spot in enterprise cloud security reviews. Security teams that have hardened Entra ID, tuned Defender for Cloud, and locked down storage accounts often overlook the ML estate — which is running Jupyter notebooks with attached managed identities, training jobs with broad IAM grants, and pipelines that pull secrets from Key Vault.

This guide covers the attack paths that matter and the specific controls that close them.

The Attack Surface

An Azure ML workspace ties together several Azure services into a functional unit:

  • Compute instances — Azure VMs running JupyterLab with an assigned managed identity
  • Compute clusters — Scalable VM pools used for training jobs and pipeline steps
  • Datastores — Registered connections to storage accounts, Azure Data Lake, SQL databases
  • Model registry — Versioned storage of trained models and their associated artifacts
  • Key Vault — Workspace secrets and dataset credentials stored here by default
  • Pipelines — Multi-step ML workflows that execute code across compute targets

The managed identities assigned to compute instances and clusters are the primary risk surface. If those identities carry overpermissioned IAM roles, an attacker who gains code execution on a compute instance has a path to broader Azure access.

Attack Path 1: Managed Identity Credential Theft from Compute Instance

Every Azure ML compute instance runs with an attached managed identity. That identity is accessible via the Azure Instance Metadata Service (IMDS) at http://169.254.169.254/metadata/identity/oauth2/token.

From a notebook running on the compute instance:

import requests

response = requests.get(
    "http://169.254.169.254/metadata/identity/oauth2/token",
    params={"api-version": "2018-02-01", "resource": "https://management.azure.com/"},
    headers={"Metadata": "true"}
)
token = response.json()["access_token"]
# Token can now be used against any ARM endpoint the identity has permissions to

This works from a terminal, a notebook cell, or a training script. No special privileges required — it’s a network call from inside the VM.

The impact depends on what the managed identity can do. Common dangerous grants seen in production:

  • Contributor on the resource group (attacker can create new resources, modify existing ones)
  • Storage Blob Data Owner on all storage accounts in the workspace resource group
  • Key Vault Secrets Officer on the workspace Key Vault
  • In worst cases: Owner on the subscription (inherited from overly permissive workspace setup)

Remediation: Audit managed identity role assignments. The system-assigned identity on a compute instance needs Storage Blob Data Contributor scoped to the workspace’s default storage account only. It does not need subscription-level permissions. Use az role assignment list --assignee <object-id> to enumerate current grants.

Attack Path 2: Workspace Key Vault Access

Azure ML workspaces create a dedicated Key Vault and store workspace secrets, dataset credentials, and sometimes application secrets there. By default, the workspace has access, and so does any compute identity attached to that workspace.

The Key Vault access policy or RBAC configuration is often set with Key Vault Secrets User for the entire workspace scope. Enumerating and exfiltrating secrets:

# From a compute instance terminal
az login --identity
az keyvault secret list --vault-name <workspace-keyvault-name>
az keyvault secret show --vault-name <workspace-keyvault-name> --name <secret-name>

Workspace Key Vaults frequently contain: database connection strings, external API keys, storage SAS tokens, and credentials for on-premises data sources.

Remediation: Switch the workspace Key Vault to RBAC mode (--enable-rbac-authorization true). Assign Key Vault Secrets User only to the specific identities that need specific secrets. Audit what secrets are stored — application secrets that don’t belong in the ML workspace should be moved or removed.

Attack Path 3: Datastore Credential Extraction

Azure ML datastores register connections to storage accounts and databases. Depending on the registration type, credentials may be stored in the workspace or in Key Vault:

from azureml.core import Workspace, Datastore

ws = Workspace.from_config()
ds = Datastore.get(ws, "my_datastore")
print(ds.account_name)
print(ds.account_key)  # Returns plaintext key if credential-based registration

Datastores registered with an account key rather than a managed identity expose that key to any user with AzureML Data Scientist or higher on the workspace. This role is broadly granted to ML practitioners and is not typically treated as a privileged role by cloud security teams.

Remediation: Register datastores using managed identity authentication (credential_type='None') rather than account keys. For existing credential-based datastores, rotate the keys and migrate to managed identity authentication.

Attack Path 4: Training Job IAM Escalation

Training jobs run with the compute cluster’s managed identity. If a malicious actor can submit a training job — or modify a training script in a shared pipeline — they can execute arbitrary code under that identity.

AzureML Data Scientist role has Microsoft.MachineLearningServices/workspaces/experiments/runs/write which includes submitting training jobs. In a multi-team workspace, this means any data scientist can run code under the shared cluster identity.

A training script that exfiltrates the IMDS token runs silently in the training logs. Without active monitoring of training job outputs for suspicious API calls, this is difficult to detect after the fact.

Remediation: Use separate compute clusters per team with scoped managed identities. Grant each cluster identity only the permissions it needs for its specific workload. Enable Azure Monitor logging for training job metadata to detect anomalous job submissions outside business hours or from unfamiliar users.

Attack Path 5: Model Registry Tampering (Model Poisoning)

Users with AzureML Data Scientist can register and modify model versions. In a production MLOps pipeline that automatically promotes the latest registered model version to serving, a malicious model registration can insert poisoned model artifacts into the deployment pipeline.

This is a supply chain attack within the ML infrastructure rather than a traditional cloud attack — but the blast radius reaches whatever the serving endpoint can access.

Remediation: Enable model registry approvals for production model promotion. Require separate identities for model registration (development) and model deployment (production). Implement integrity checks (hash verification) on model artifacts before serving.

Hardening Checklist

Identity and access:

  • Audit all managed identity role assignments — no subscription-level Contributor/Owner
  • Switch workspace Key Vault to RBAC mode
  • Scope managed identity permissions to the minimum required per compute target
  • Separate workspace RBAC assignments: read-only roles for most users, privileged roles only for workspace administrators

Data access:

  • Migrate datastores from credential-based to managed identity authentication
  • Enable private endpoints on the workspace and associated storage accounts
  • Disable public network access where operational requirements allow

Compute:

  • Enable workspace-level network isolation (no public IP on compute instances)
  • Restrict outbound connectivity from compute clusters to required endpoints only
  • Enable logging for compute instance access and training job submissions

Monitoring:

  • Alert on IMDS token requests from compute instances to unexpected Azure resources
  • Alert on Key Vault secret enumeration from workspace-associated identities
  • Alert on training job submissions outside business hours from non-service accounts

Azure ML workspaces that haven’t had a security review are often running with the default permissive configuration that was convenient at setup. The managed identity exposure alone — a notebook with Contributor on the resource group — is enough for an attacker with code execution on that compute instance to achieve significant lateral movement within the subscription.

← All Analysis Subscribe via RSS