Azure Machine Learning workspaces should be encrypted with a customer-managed key (CMK)

What does the recommendation "Azure Machine Learning workspaces should be encrypted with a customer-managed key (CMK)" check?

Flags any Azure Machine Learning workspace whose metadata is encrypted with the default Microsoft-managed key rather than a customer-managed key from your own Azure Key Vault. The scope is the workspace's encryption-at-rest of metadata held in the dependent Cosmos DB, Azure AI Search and Storage resources. It does not check the OS disk of compute clusters or compute instances, which cannot take a customer-managed key, and it does not verify key rotation, key vault soft delete or purge protection, nor the encryption of the data and models you store in attached datastores.

Why does "Azure Machine Learning workspaces should be encrypted with a customer-managed key (CMK)" matter?

With the default key, Microsoft holds the encryption key for the metadata your workspace generates: experiment metadata, pipeline definitions and references that can describe sensitive datasets and model logic. For regulated workloads in finance, health or government this fails the requirement to retain sole custody of the key and to be able to revoke access yourself. A customer-managed key lets you rotate or disable the key on your own schedule, cutting access to the encrypted metadata without waiting on a provider, which is often a contractual or audit precondition for running models on regulated data in Azure.

How do I fix "Azure Machine Learning workspaces should be encrypted with a customer-managed key (CMK)"?

1. Create or reuse an Azure Key Vault in the same subscription as the workspace with soft delete and purge protection enabled, generate an RSA key (3072-bit or larger), then add an access policy granting Azure Cosmos DB the Get, Unwrap Key and Wrap Key permissions on that key.
2. Create the workspace with the key, because a customer-managed key can only be set at creation time. In a CLI v2 YAML file add a 'customer_managed_key' block with 'key_vault' set to the vault resource ID and 'key_uri' set to the key URL, then run 'az ml workspace create -g <resource-group> --file workspace.yml'. After creation the key can be rotated only to another key in the same vault.
3. Make CMK the default for new workspaces in your Bicep or Terraform module by populating the workspace 'encryption' property with 'status: Enabled' and the 'keyVaultProperties' (key vault ARM ID and key identifier), and enforce it by assigning the built-in audit policy: pid=$(az policy definition list --query "[?displayName=='Azure Machine Learning workspaces should be encrypted with a customer-managed key'].name" -o tsv); az policy assignment create --name aml-cmk --policy "$pid" --scope <scope>.

# 1. Free, universal fix: enable Transparent Data Encryption on a SQL database.
az sql db tde set \
  --resource-group rg-data \
  --server sql-fintech-prod \
  --database payments \
  --status Enabled

# 2. Free, universal fix: encrypt VM temp disks, caches and data flows.
az feature register --namespace Microsoft.Compute --name EncryptionAtHost
az vm deallocate --resource-group rg-app --name vm-tooling-01
az vm update --resource-group rg-app --name vm-tooling-01 \
  --set securityProfile.encryptionAtHost=true
az vm start --resource-group rg-app --name vm-tooling-01

# 3. Only where required: customer-managed key on a storage account.
az storage account update \
  --name stbankingprod \
  --resource-group rg-data \
  --encryption-key-source Microsoft.Keyvault \
  --encryption-key-vault "https://kv-banking-cmk.vault.azure.net" \
  --encryption-key-name sa-cmk

echo "TDE on, host encryption on, CMK applied to the one regulated store."