Delen via

Verificatie instellen tussen Azure Machine Learning en andere services

  • Artikel

VAN TOEPASSING OP:Azure CLI ml extension v2 (current)Python SDK azure-ai-ml v2 (current)

Azure Machine Learning is samengesteld uit meerdere Azure-services. Er zijn meerdere manieren waarop verificatie kan plaatsvinden tussen Azure Machine Learning en de services waarvoor deze verificatie afhankelijk is.

  • De Azure Machine Learning-werkruimte maakt gebruik van een beheerde identiteit om te communiceren met andere services. Dit is standaard een door het systeem toegewezen beheerde identiteit. U kunt in plaats daarvan ook een door de gebruiker toegewezen beheerde identiteit gebruiken.
  • Azure Machine Learning maakt gebruik van Azure Container Registry (ACR) om Docker-installatiekopieën op te slaan die worden gebruikt voor het trainen en implementeren van modellen. Als u azure Machine Learning toestaat om automatisch ACR te maken, wordt het beheerdersaccount ingeschakeld.
  • Het Azure Machine Learning-rekencluster maakt gebruik van een beheerde identiteit om verbindingsgegevens op te halen voor gegevensarchieven uit Azure Key Vault en Docker-installatiekopieën op te halen uit ACR. U kunt ook op identiteit gebaseerde toegang tot gegevensarchieven configureren. In plaats daarvan wordt de beheerde identiteit van het rekencluster gebruikt.
  • Gegevenstoegang kan plaatsvinden via meerdere paden, afhankelijk van de gegevensopslagservice en uw configuratie. Verificatie voor het gegevensarchief kan bijvoorbeeld een accountsleutel, token, beveiligingsprincipaal, beheerde identiteit of gebruikersidentiteit gebruiken.
  • Beheerde online-eindpunten kunnen een beheerde identiteit gebruiken om toegang te krijgen tot Azure-resources bij het uitvoeren van deductie. Raadpleeg Toegang tot Azure-resources vanaf een online eindpunt voor meer informatie.

Vereisten

Voordat u de stappen in dit artikel volgt, moet u ervoor zorgen dat u over de volgende vereisten beschikt:

  • Een Azure Machine Learning-werkruimte. Als u er nog geen hebt, gebruikt u de stappen in de quickstart: artikel Werkruimtebronnen maken om er een te maken.

  • De Azure CLI en de ml extensie of de Azure Machine Learning Python SDK v2:

    • Zie De CLI (v2) installeren, instellen en gebruiken om de Azure CLI en extensie te installeren.

      Belangrijk

      In de CLI-voorbeelden in dit artikel wordt ervan uitgegaan dat u de Bash-shell (of compatibele) shell gebruikt. Bijvoorbeeld vanuit een Linux-systeem of Windows-subsysteem voor Linux.

    • Gebruik de volgende opdracht om de Python SDK v2 te installeren:

      pip install azure-ai-ml azure-identity

      Gebruik de volgende opdracht om een bestaande installatie van de SDK bij te werken naar de nieuwste versie:

      pip install --upgrade azure-ai-ml azure-identity

      Zie De Python SDK v2 voor Azure Machine Learning installeren voor meer informatie.

  • Als u rollen wilt toewijzen, moet de aanmelding voor uw Azure-abonnement de rol Managed Identity Operator hebben of een andere rol die de vereiste acties (zoals Eigenaar) verleent.

  • U moet bekend zijn met het maken en werken met beheerde identiteiten.

Identiteitstypen voor werkruimten

De Azure Machine Learning-werkruimte maakt gebruik van een beheerde identiteit om te communiceren met andere services. Er worden meerdere identiteitstypen ondersteund voor Azure Machine Learning.

Type beheerde identiteit Roltoewijzing maken Doel
Door het systeem toegewezen (SAI) Beheerd door Microsoft Levenscyclus gekoppeld aan resource; gebruik van één resource; eenvoudig om aan de slag te gaan
Door het systeem toegewezen+gebruiker toegewezen (SAI+UAI) Beheerd door u Onafhankelijke levenscyclus voor door de gebruiker toegewezen identiteit, multi-resourcegebruik, beheert de minst bevoegde toegang. Toegang tot gegevens in trainingstaken.

Zodra een werkruimte is gemaakt met het type SAI-identiteit, kan deze worden bijgewerkt naar SAI+UAI, maar niet terug van SAI+UAI naar SAI. U kunt meerdere door de gebruiker toegewezen identiteiten toewijzen aan dezelfde werkruimte.

Azure Container Registry en identiteitstypen

Deze tabel bevat de ondersteuningsmatrix bij het verifiëren bij Azure Container Registry, afhankelijk van de verificatiemethode en de configuratie voor openbare netwerktoegang van Azure Container Registry.

Verificatiemethode Openbare netwerktoegang
uitgeschakeld		 Openbare netwerktoegang van Azure Container Registry
ingeschakeld
Beheerder ✓ ✓
Door het werkruimtesysteem toegewezen beheerde identiteit ✓ ✓
Door de gebruiker toegewezen beheerde identiteit
van de werkruimte waarbij de rol ACRPull is toegewezen aan de identiteit		 ✓

Door de gebruiker toegewezen beheerde identiteit

Werkplek

U kunt een door de gebruiker toegewezen beheerde identiteit toevoegen bij het maken van een Azure Machine Learning-werkruimte vanuit Azure Portal. Gebruik de volgende stappen tijdens het maken van de werkruimte:

  1. Selecteer op de pagina Basisinformatie het Azure Storage-account, Azure Container Registry en Azure Key Vault dat u wilt gebruiken met de werkruimte.
  2. Selecteer op de pagina Identiteit de door de gebruiker toegewezen identiteit en selecteer vervolgens de beheerde identiteit die u wilt gebruiken.

De volgende Azure RBAC-roltoewijzingen zijn vereist voor uw door de gebruiker toegewezen beheerde identiteit voor uw Azure Machine Learning-werkruimte voor toegang tot gegevens op de aan de werkruimte gekoppelde resources.

Bron Machtiging
Azure Machine Learning-werkruimte Inzender
Azure Storage Inzender (besturingsvlak) + Inzender voor opslagblobgegevens (gegevensvlak, optioneel, om een voorbeeld van gegevens in te schakelen in de Azure Machine Learning-studio)
Azure Key Vault (wanneer u een RBAC-machtigingsmodel gebruikt) Inzender (besturingsvlak) + Key Vault-beheerder (gegevensvlak)
Azure Key Vault (bij gebruik van machtigingsmodel voor toegangsbeleid) Inzender + machtigingen voor toegangsbeleid naast opschoningsbewerkingen
Azure Container Registry Inzender
Azure Application Insights Inzender

Voor het automatisch maken van roltoewijzingen voor uw door de gebruiker toegewezen beheerde identiteit kunt u deze ARM-sjabloon gebruiken.

Tip

Voor een werkruimte met door de klant beheerde sleutels voor versleuteling kunt u een door de gebruiker toegewezen beheerde identiteit doorgeven om te verifiëren van opslag naar Key Vault. Gebruik de user-assigned-identity-for-cmk-encryption parameters (CLI) of user_assigned_identity_for_cmk_encryption (SDK) om de beheerde identiteit door te geven. Deze beheerde identiteit kan hetzelfde of verschillend zijn als de primaire door de gebruiker toegewezen beheerde identiteit van de werkruimte.

Als u een werkruimte wilt maken met meerdere door de gebruiker toegewezen identiteiten, gebruikt u een van de volgende methoden:

VAN TOEPASSING OP: Azure CLI ml-extensie v2 (huidige)

az ml workspace create -f workspace_creation_with_multiple_UAIs.yml --subscription <subscription ID> --resource-group <resource group name> --name <workspace name>

Waar de inhoud van workspace_creation_with_multiple_UAIs.yml als volgt is:

location: <region name>
identity:
   type: user_assigned
   user_assigned_identities:
    '<UAI resource ID 1>': {}
    '<UAI resource ID 2>': {}
storage_account: <storage acccount resource ID>
key_vault: <key vault resource ID>
image_build_compute: <compute(virtual machine) resource ID>
primary_user_assigned_identity: <one of the UAI resource IDs in the above list>

Als u door de gebruiker toegewezen identiteiten voor een werkruimte wilt bijwerken, moet u een nieuwe identiteit toevoegen of de bestaande identiteiten verwijderen door een van de volgende methoden te gebruiken:

VAN TOEPASSING OP: Azure CLI ml-extensie v2 (huidige)

az ml workspace update -f workspace_update_with_multiple_UAIs.yml --subscription <subscription ID> --resource-group <resource group name> --name <workspace name>

Waar de inhoud van workspace_update_with_multiple_UAIs.yml als volgt is:

identity:
   type: user_assigned
   user_assigned_identities:
    '<UAI resource ID 1>': {}
    '<UAI resource ID 2>': {}
primary_user_assigned_identity: <one of the UAI resource IDs in the above list>

Tip

Als u een nieuwe UAI wilt toevoegen, kunt u de nieuwe UAI-id opgeven onder de sectie user_assigned_identities naast de bestaande UA's, moet u alle bestaande UAI-id's doorgeven.
Als u een of meer bestaande UURI's wilt verwijderen, kunt u de UAI-id's plaatsen die moeten worden bewaard onder de sectie user_assigned_identities, worden de overige UAI-id's verwijderd.

Een door de gebruiker toegewezen beheerde identiteit toevoegen aan een werkruimte, naast een door het systeem toegewezen identiteit

In sommige scenario's moet u mogelijk een door de gebruiker toegewezen beheerde identiteit gebruiken, naast de standaard door het systeem toegewezen werkruimte-id. Als u een door de gebruiker toegewezen beheerde identiteit wilt toevoegen zonder de bestaande werkruimte-identiteit te wijzigen, gebruikt u de volgende stappen:

  1. Een door een gebruiker toegewezen beheerde identiteit maken. Sla de id op voor de beheerde identiteit die u maakt.

  2. Als u de beheerde identiteit aan uw werkruimte wilt koppelen, hebt u een YAML-bestand nodig waarmee de identiteit wordt opgegeven. Hier volgt een voorbeeld van de inhoud van het YAML-bestand. Vervang de <TENANT_ID>, <RESOURCE_GROUP>en <USER_MANAGED_ID> door uw waarden.

    identity:
    type: system_assigned,user_assigned
    tenant_id: <TENANT_ID>
    user_assigned_identities:
        '/subscriptions/<SUBSCRIPTION_ID/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<USER_MANAGED_ID>':
        {}

  3. Gebruik de Azure CLI-opdracht az ml workspace update om uw werkruimte bij te werken. Geef het YAML-bestand op uit de vorige stap met behulp van de --file parameter. In het volgende voorbeeld ziet u hoe deze opdracht eruitziet:

    az ml workspace update --resource-group <RESOURCE_GROUP> --name <WORKSPACE_NAME> --file <YAML_FILE_NAME>.yaml

Rekencluster

Notitie

Azure Machine Learning-rekenclusters ondersteunen slechts één door het systeem toegewezen identiteit of meerdere door de gebruiker toegewezen identiteiten, niet beide gelijktijdig.

De standaard beheerde identiteit is de door het systeem toegewezen beheerde identiteit of de eerste door de gebruiker toegewezen beheerde identiteit.

Tijdens een uitvoering zijn er twee toepassingen van een identiteit:

  1. Het systeem gebruikt een identiteit om de opslagkoppelingen van de gebruiker, containerregister en gegevensarchieven in te stellen.

    • In dit geval gebruikt het systeem de standaard beheerde identiteit.

  2. U past een identiteit toe voor toegang tot resources vanuit de code voor een ingediende taak:

    • Geef in dit geval de client_id op die overeenkomt met de beheerde identiteit die u wilt gebruiken om een referentie op te halen.
    • U kunt ook de client-id van de door de gebruiker toegewezen identiteit ophalen via de omgevingsvariabele DEFAULT_IDENTITY_CLIENT_ID .

    Als u bijvoorbeeld een token wilt ophalen voor een gegevensarchief met de standaard beheerde identiteit:

    client_id = os.environ.get('DEFAULT_IDENTITY_CLIENT_ID')
credential = ManagedIdentityCredential(client_id=client_id)
token = credential.get_token('https://storage.azure.com/')

Gebruik een van de volgende methoden om een rekencluster met beheerde identiteit te configureren:

VAN TOEPASSING OP: Azure CLI ml-extensie v2 (huidige)

az ml compute create -f create-cluster.yml

Waar de inhoud van create-cluster.yml als volgt is:

$schema: https://azuremlschemas.azureedge.net/latest/amlCompute.schema.json 
name: basic-example
type: amlcompute
size: STANDARD_DS3_v2
min_instances: 0
max_instances: 2
idle_time_before_scale_down: 120
identity:
  type: user_assigned
  user_assigned_identities: 
    - resource_id: "identity_resource_id"

Ter vergelijking is het volgende voorbeeld afkomstig van een YAML-bestand dat een cluster maakt dat gebruikmaakt van een door het systeem toegewezen beheerde identiteit:

$schema: https://azuremlschemas.azureedge.net/latest/amlCompute.schema.json 
name: basic-example
type: amlcompute
size: STANDARD_DS3_v2
min_instances: 0
max_instances: 2
idle_time_before_scale_down: 120
identity:
  type: system_assigned

Als u een bestaand rekencluster hebt, kunt u schakelen tussen door de gebruiker beheerde en door het systeem beheerde identiteit. In de volgende voorbeelden ziet u hoe u de configuratie kunt wijzigen:

Door de gebruiker toegewezen beheerde identiteit

export MSI_NAME=my-cluster-identity
export COMPUTE_NAME=mycluster-msi

does_compute_exist()
{
  if [ -z $(az ml compute show -n $COMPUTE_NAME --query name) ]; then
    echo false
  else
    echo true
  fi
}

echo "Creating MSI $MSI_NAME"
# Get the resource id of the identity
IDENTITY_ID=$(az identity show --name "$MSI_NAME" --query id -o tsv | tail -n1 | tr -d "[:cntrl:]" || true)
if [[ -z $IDENTITY_ID ]]; then
    IDENTITY_ID=$(az identity create -n "$MSI_NAME" --query id -o tsv | tail -n1 | tr -d "[:cntrl:]")
fi
echo "MSI created: $MSI_NAME"
sleep 15 # Let the previous command finish: https://github.com/Azure/azure-cli/issues/8530


echo "Checking if compute $COMPUTE_NAME already exists"
if [ "$(does_compute_exist)" == "true" ]; then
  echo "Skipping, compute: $COMPUTE_NAME exists"
else
  echo "Provisioning compute: $COMPUTE_NAME"
  az ml compute create --name "$COMPUTE_NAME" --type amlcompute --identity-type user_assigned --user-assigned-identities "$IDENTITY_ID"
fi
az ml compute update --name "$COMPUTE_NAME" --identity-type user_assigned --user-assigned-identities "$IDENTITY_ID"

Door het systeem toegewezen beheerde identiteit

export COMPUTE_NAME=mycluster-sa

does_compute_exist()
{
  if [ -z $(az ml compute show -n $COMPUTE_NAME --query name) ]; then
    echo false
  else
    echo true
  fi
}

echo "Checking if compute $COMPUTE_NAME already exists"
if [ "$(does_compute_exist)" == "true" ]; then
  echo "Skipping, compute: $COMPUTE_NAME exists"
else
  echo "Provisioning compute: $COMPUTE_NAME"
  az ml compute create --name "$COMPUTE_NAME" --type amlcompute
fi

az ml compute update --name "$COMPUTE_NAME" --identity-type system_assigned

Gegevensopslag

Wanneer u een gegevensarchief maakt dat gebruikmaakt van op identiteit gebaseerde gegevenstoegang, wordt uw Azure-account (Microsoft Entra-token) gebruikt om te bevestigen dat u gemachtigd bent om toegang te krijgen tot de opslagservice. In het scenario voor gegevenstoegang op basis van identiteit worden er geen verificatiereferenties opgeslagen. Alleen de gegevens van het opslagaccount worden opgeslagen in het gegevensarchief.

Gegevensarchieven die gebruikmaken van op referenties gebaseerde verificatiecacheverbindingsgegevens , zoals de sleutel van uw opslagaccount of SAS-token, daarentegen, in de sleutelkluis die is gekoppeld aan de werkruimte. Deze benadering heeft de beperking dat andere werkruimtegebruikers met voldoende machtigingen deze referenties kunnen ophalen. Dit kan een beveiligingsprobleem zijn voor sommige organisaties.

Zie het artikel Over gegevensbeheer voor meer informatie over hoe gegevenstoegang wordt geverifieerd. Zie Gegevensarchieven maken voor informatie over het configureren van identiteitstoegang tot gegevens.

Er zijn twee scenario's waarin u op identiteit gebaseerde gegevenstoegang kunt toepassen in Azure Machine Learning. Deze scenario's zijn geschikt voor op identiteit gebaseerde toegang wanneer u met vertrouwelijke gegevens werkt en gedetailleerdere gegevenstoegangsbeheer nodig hebt:

  • Toegang tot opslagservices
  • Machine Learning-modellen trainen

Met de op identiteit gebaseerde toegang kunt u op rollen gebaseerd toegangsbeheer (RBAC) gebruiken om te beperken welke identiteiten, zoals gebruikers of rekenresources, toegang hebben tot de gegevens.

Toegang tot opslagservices

U kunt verbinding maken met opslagservices via op identiteit gebaseerde gegevenstoegang met Azure Machine Learning-gegevensarchieven.

Wanneer u op identiteit gebaseerde gegevenstoegang gebruikt, vraagt Azure Machine Learning u om uw Microsoft Entra-token voor verificatie voor gegevenstoegang in plaats van uw referenties in het gegevensarchief te bewaren. Met deze aanpak kan gegevenstoegang op opslagniveau worden beheerd en blijven referenties vertrouwelijk.

Hetzelfde gedrag is van toepassing wanneer u interactief met gegevens werkt via een Jupyter Notebook op uw lokale computer of rekenproces.

Notitie

Referenties die zijn opgeslagen via verificatie op basis van referenties, zijn abonnements-id's, SAS-tokens (Shared Access Signature) en opslagtoegangssleutel en service-principalgegevens, zoals client-id's en tenant-id's.

Om ervoor te zorgen dat u veilig verbinding maakt met uw opslagservice in Azure, moet u voor Azure Machine Learning gemachtigd zijn om toegang te krijgen tot de bijbehorende gegevensopslag.

Waarschuwing

Toegang tussen tenants tot opslagaccounts wordt niet ondersteund. Als toegang tussen tenants nodig is voor uw scenario, neemt u contact op met de alias van het Azure Machine Learning Data Support-team op amldatasupport@microsoft.com voor hulp bij een aangepaste codeoplossing.

Gegevenstoegang op basis van identiteit ondersteunt alleen verbindingen met de volgende opslagservices.

  • Azure Blob Storage
  • Azure Data Lake Storage Gen1
  • Azure Data Lake Storage Gen2

Als u toegang wilt krijgen tot deze opslagservices, moet u ten minste toegang hebben tot opslagblobgegevenslezer tot het opslagaccount. Alleen eigenaren van opslagaccounts kunnen uw toegangsniveau wijzigen via Azure Portal.

Toegang tot gegevens voor trainingstaken op rekenproces met behulp van beheerde identiteit

Bepaalde machine learning-scenario's omvatten het werken met persoonlijke gegevens. In dergelijke gevallen hebben gegevenswetenschappers mogelijk geen directe toegang tot gegevens als Microsoft Entra-gebruikers. In dit scenario kan de beheerde identiteit van een rekenproces worden gebruikt voor verificatie van gegevenstoegang. In dit scenario kunnen de gegevens alleen worden geopend vanuit een rekenproces of een machine learning-rekencluster dat een trainingstaak uitvoert. Met deze methode verleent de beheerder het rekenproces of het rekencluster beheerde machtigingen voor opslagblobgegevenslezer voor de opslag. De individuele gegevenswetenschappers hoeven geen toegang te krijgen.

Verificatie inschakelen met beheerde identiteit voor rekenkracht:

  • Rekenproces maken waarvoor beheerde identiteit is ingeschakeld. Zie de sectie Rekencluster , of voor het rekenproces, de sectie Beheerde identiteit toewijzen.

    Belangrijk

    Als het rekenproces ook is geconfigureerd voor inactiviteit, wordt het rekenproces niet afgesloten vanwege inactiviteit, tenzij de beheerde identiteit inzendertoegang heeft tot de Azure Machine Learning-werkruimte. Zie Beheer toegang tot Azure Machine Learning-werkruimten voor meer informatie over machtigingen.

  • Verdeel een beheerde identiteit voor rekenkracht ten minste de rol opslagblobgegevenslezer in het opslagaccount.

  • Maak gegevensarchieven waarvoor verificatie op basis van identiteit is ingeschakeld. Zie Gegevensarchieven maken.

Notitie

De naam van de door het systeem beheerde identiteit voor het rekenproces of cluster heeft de indeling /workspace-name/computes/compute-name in uw Microsoft Entra-id.

Zodra verificatie op basis van identiteit is ingeschakeld, wordt de beheerde identiteit voor berekeningen standaard gebruikt bij het openen van gegevens in uw trainingstaken. U kunt zich desgewenst verifiëren met gebruikersidentiteit met behulp van de stappen die worden beschreven in de volgende sectie.

Zie op rollen gebaseerd toegangsbeheer voor informatie over het configureren van Azure RBAC voor de opslag.

Toegang tot gegevens voor trainingstaken op rekenclusters met behulp van gebruikersidentiteit

VAN TOEPASSING OP: Azure CLI ml-extensie v2 (huidige)

Bij het trainen van Azure Machine Learning-rekenclusters kunt u zich verifiëren bij opslag met uw Microsoft Entra-token van uw gebruiker.

Met deze verificatiemodus kunt u het volgende doen:

  • Stel gedetailleerde machtigingen in, waarbij verschillende werkruimtegebruikers toegang hebben tot verschillende opslagaccounts of mappen binnen opslagaccounts.
  • Laat gegevenswetenschappers bestaande machtigingen voor opslagsystemen opnieuw gebruiken.
  • Opslagtoegang controleren omdat in de opslaglogboeken wordt weergegeven welke identiteiten zijn gebruikt voor toegang tot gegevens.

Belangrijk

Deze functionaliteit heeft de volgende beperkingen

  • De functie wordt ondersteund voor experimenten die zijn verzonden via de Azure Machine Learning CLI en Python SDK V2, maar niet via ML Studio.
  • Beheerde identiteit van gebruikers en compute kan niet worden gebruikt voor verificatie binnen dezelfde taak.
  • Voor pijplijntaken raden we u aan om de gebruikersidentiteit in te stellen op het niveau van de afzonderlijke stap die wordt uitgevoerd op een berekening, in plaats van op het niveau van de hoofdpijplijn. ( Hoewel identiteitsinstelling wordt ondersteund op zowel hoofdpijplijn- als stapniveaus, heeft de instelling op stapniveau voorrang als beide zijn ingesteld. Voor pijplijnen met pijplijnonderdelen moet de identiteit echter worden ingesteld op afzonderlijke stappen die worden uitgevoerd. De identiteit die is ingesteld op het hoofdpijplijn- of pijplijnonderdeelniveau, werkt niet. Daarom raden we u aan identiteit in te stellen op het niveau van de afzonderlijke stap om het eenvoudig te maken.)

In de volgende stappen wordt beschreven hoe u gegevenstoegang met gebruikersidentiteit instelt voor trainingstaken op rekenclusters vanuit CLI.

  1. Verdeel de gebruikersidentiteit toegang tot opslagbronnen. U kunt bijvoorbeeld StorageBlobReader toegang verlenen tot het specifieke opslagaccount dat u wilt gebruiken of op ACL gebaseerde machtigingen verlenen aan specifieke mappen of bestanden in Azure Data Lake Gen 2-opslag.

  2. Maak een Azure Machine Learning-gegevensarchief zonder referenties in de cache voor het opslagaccount. Als een gegevensarchief referenties in de cache heeft, zoals de sleutel van het opslagaccount, worden deze referenties gebruikt in plaats van de gebruikersidentiteit.

  3. Dien een trainingstaak in met de eigenschapsidentiteit ingesteld op type: user_identity, zoals wordt weergegeven in de volgende taakspecificatie. Tijdens de trainingstaak vindt de verificatie voor opslag plaats via de identiteit van de gebruiker die de taak verzendt.

    Notitie

    Als de id-eigenschap niet is opgegeven en het gegevensarchief geen referenties in de cache heeft, wordt de beheerde identiteit voor berekening de terugvaloptie.

    command: |
echo "--census-csv: ${{inputs.census_csv}}"
python hello-census.py --census-csv ${{inputs.census_csv}}
code: src
inputs:
census_csv:
    type: uri_file 
    path: azureml://datastores/mydata/paths/census.csv
environment: azureml:AzureML-sklearn-1.0-ubuntu20.04-py38-cpu@latest
compute: azureml:cpu-cluster
identity:
type: user_identity

In de volgende stappen wordt beschreven hoe u gegevenstoegang met gebruikersidentiteit instelt voor trainingstaken op rekenclusters vanuit de Python SDK.

  1. Gegevenstoegang verlenen en gegevensopslag maken zoals hierboven beschreven voor CLI.

  2. Dien een trainingstaak in met de identiteitsparameter die is ingesteld op azure.ai.ml.UserIdentityConfiguration. Met deze parameterinstelling kan de taak toegang krijgen tot gegevens namens de gebruiker die de taak indient.

    from azure.ai.ml import command
from azure.ai.ml.entities import Data, UriReference
from azure.ai.ml import Input
from azure.ai.ml.constants import AssetTypes
from azure.ai.ml import UserIdentityConfiguration

# Specify the data location
my_job_inputs = {
    "input_data": Input(type=AssetTypes.URI_FILE, path="<path-to-my-data>")
}

# Define the job
job = command(
    code="<my-local-code-location>", 
    command="python <my-script>.py --input_data ${{inputs.input_data}}",
    inputs=my_job_inputs,
    environment="AzureML-sklearn-0.24-ubuntu18.04-py37-cpu:9",
    compute="<my-compute-cluster-name>",
    identity= UserIdentityConfiguration() 
)
# submit the command
returned_job = ml_client.jobs.create_or_update(job)

Belangrijk

Tijdens het verzenden van taken met verificatie waarbij gebruikersidentiteit is ingeschakeld, worden de momentopnamen van de code beschermd tegen manipulatie door controlesomvalidatie. Als u bestaande pijplijnonderdelen hebt en deze wilt gebruiken met verificatie waarvoor gebruikersidentiteit is ingeschakeld, moet u deze mogelijk opnieuw uploaden. Anders kan de taak mislukken tijdens de validatie van de controlesom.

Werken met virtuele netwerken

Standaard kan Azure Machine Learning niet communiceren met een opslagaccount dat zich achter een firewall of in een virtueel netwerk bevindt.

U kunt opslagaccounts zo configureren dat alleen toegang vanuit specifieke virtuele netwerken is toegestaan. Deze configuratie vereist extra stappen om ervoor te zorgen dat gegevens niet buiten het netwerk worden gelekt. Dit gedrag is hetzelfde voor gegevenstoegang op basis van referenties. Zie Gegevensexfiltratie voorkomen voor meer informatie.

Als uw opslagaccount instellingen voor het virtuele netwerk heeft, bepaalt u welk identiteitstype en welke machtigingen er nodig zijn. Voor voorbeeldgegevens en gegevensprofiel bepalen de instellingen van het virtuele netwerk welk type identiteit wordt gebruikt om gegevenstoegang te verifiëren.

  • In scenario's waarin alleen bepaalde IP-adressen en subnetten toegang hebben tot de opslag, gebruikt Azure Machine Learning de msi van de werkruimte om gegevensvoorbeelden en -profielen uit te voeren.

  • Als uw opslag ADLS Gen 2 of Blob is en instellingen voor het virtuele netwerk heeft, kunnen klanten msi van gebruikersidentiteiten of werkruimten gebruiken, afhankelijk van de instellingen voor het gegevensarchief die tijdens het maken zijn gedefinieerd.

  • Als de instelling voor het virtuele netwerk 'Toestaan dat Azure-services in de lijst met vertrouwde services toegang krijgen tot dit opslagaccount' is, wordt werkruimte-MSI gebruikt.

Scenario: Azure Container Registry zonder beheerdersgebruiker

Wanneer u de gebruiker met beheerdersrechten voor ACR uitschakelt, gebruikt Azure Machine Learning een beheerde identiteit om Docker-installatiekopieën te bouwen en op te halen. Er zijn twee werkstromen bij het configureren van Azure Machine Learning voor het gebruik van een ACR waarbij de gebruiker met beheerdersrechten is uitgeschakeld:

  • Sta Azure Machine Learning toe om het ACR-exemplaar te maken en schakel daarna de gebruiker met beheerdersrechten uit.
  • Breng een bestaande ACR met de gebruiker met beheerdersrechten al uitgeschakeld.

Azure Machine Learning met automatisch gemaakte ACR-exemplaar

  1. Maak een nieuwe Azure Machine Learning-werkruimte.

  2. Voer een actie uit waarvoor Azure Container Registry is vereist. Bijvoorbeeld de zelfstudie: Uw eerste model trainen.

  3. Haal de naam op van de ACR die door het cluster is gemaakt.

    VAN TOEPASSING OP: Azure CLI ml-extensie v2 (huidige)

    az ml workspace show --name <my workspace name> \
--resource-group <my resource group> \
--subscription <my subscription id> \
--query container_registry

    Met deze opdracht wordt een waarde geretourneerd die vergelijkbaar is met de volgende tekst. U wilt alleen het laatste gedeelte van de tekst. Dit is de naam van het ACR-exemplaar:

    /subscriptions/<subscription id>/resourceGroups/<my resource group>/providers/MicrosoftContainerReggistry/registries/<ACR instance name>

  4. Werk de ACR bij om de gebruiker met beheerdersrechten uit te schakelen:

    az acr update --name <ACR instance name> --admin-enabled false

Bring your own ACR

Als de ACR-beheerdergebruiker niet is toegestaan op basis van abonnementsbeleid, moet u eerst ACR zonder beheerdersgebruiker maken en deze vervolgens koppelen aan de werkruimte. Maak ACR vanuit Azure CLI zonder argument in te stellen --admin-enabled of vanuit De Azure-portal zonder beheerdersgebruiker in te schakelen. Wanneer u vervolgens een Azure Machine Learning-werkruimte maakt, geeft u de Azure-resource-id van de ACR op. In het volgende voorbeeld ziet u hoe u een nieuwe Azure Machine Learning-werkruimte maakt die gebruikmaakt van een bestaande ACR:

VAN TOEPASSING OP: Azure CLI ml-extensie v2 (huidige)

az ml workspace create -n <workspace name> \
-g <workspace resource group> \
-l <region> \
--container-registry /subscriptions/<subscription id>/resourceGroups/<acr resource group>/providers/Microsoft.ContainerRegistry/registries/<acr name>

Tip

Als u de waarde voor de --container-registry parameter wilt ophalen, gebruikt u de opdracht az acr show om informatie voor uw ACR weer te geven. Het id veld bevat de resource-id voor uw ACR.

Als u al een bestaande ACR met gebruiker met beheerdersrechten hebt uitgeschakeld, kunt u deze koppelen aan de werkruimte door deze bij te werken. In het volgende voorbeeld ziet u hoe u een Azure Machine Learning-werkruimte bijwerkt om een bestaande ACR te gebruiken:

VAN TOEPASSING OP: Azure CLI ml-extensie v2 (huidige)

az ml workspace update --update-dependent-resources \
--name <workspace name> \
--resource-group <workspace resource group> \
--container-registry /subscriptions/<subscription id>/resourceGroups/<acr resource group>/providers/Microsoft.ContainerRegistry/registries/<acr name>

Compute maken met beheerde identiteit voor toegang tot Docker-installatiekopieën voor training

Als u toegang wilt krijgen tot de werkruimte ACR, maakt u een machine learning-rekencluster met door het systeem toegewezen beheerde identiteit ingeschakeld. U kunt de identiteit inschakelen vanuit Azure Portal of Studio bij het maken van rekenkracht of vanuit Azure CLI met behulp van de onderstaande stappen. Zie het gebruik van beheerde identiteiten met rekenclusters voor meer informatie.

VAN TOEPASSING OP: Azure CLI ml-extensie v2 (huidige)

az ml compute create --name cpu-cluster --type <cluster name>  --identity-type systemassigned

Aan een beheerde identiteit wordt automatisch de ACRPull-rol in werkruimte ACR verleend om Docker-installatiekopieën voor training in te schakelen.

Notitie

Als u eerst compute maakt, moet u de ACR-rol handmatig toewijzen voordat de werkruimte ACRCR is gemaakt.

Docker-installatiekopieën gebruiken voor deductie

Nadat u ACR hebt geconfigureerd zonder beheerdersgebruiker zoals eerder beschreven, hebt u toegang tot Docker-installatiekopieën voor deductie zonder beheerderssleutels van uw Azure Kubernetes-service (AKS). Wanneer u AKS maakt of koppelt aan de werkruimte, wordt de service-principal van het cluster automatisch ACRPull-toegang tot werkruimte ACR toegewezen.

Notitie

Als u uw eigen AKS-cluster gebruikt, moet voor het cluster een service-principal zijn ingeschakeld in plaats van een beheerde identiteit.

Scenario: Een privé-Azure Container Registry gebruiken

Azure Machine Learning maakt standaard gebruik van Docker-basisinstallatiekopieën die afkomstig zijn van een openbare opslagplaats die wordt beheerd door Microsoft. Vervolgens wordt uw trainings- of deductieomgeving op deze afbeeldingen gebouwd. Zie Wat zijn ML-omgevingen? voor meer informatie.

Als u een aangepaste basisinstallatiekopieën intern voor uw onderneming wilt gebruiken, kunt u beheerde identiteiten gebruiken voor toegang tot uw persoonlijke ACR. Er zijn twee use cases:

  • Gebruik de basisinstallatiekopieën voor het trainen zoals u dat wilt.
  • Bouw een door Azure Machine Learning beheerde installatiekopieën met aangepaste installatiekopieën als basis.

Docker-basisinstallatiekopie naar machine learning-rekencluster ophalen voor training zoals is

Maak een machine learning-rekencluster met door het systeem toegewezen beheerde identiteit ingeschakeld, zoals eerder beschreven. Bepaal vervolgens de principal-id van de beheerde identiteit.

VAN TOEPASSING OP: Azure CLI ml-extensie v2 (huidige)

az ml compute show --name <cluster name> -n <workspace> -g <resource group>

U kunt het rekencluster desgewenst bijwerken om een door de gebruiker toegewezen beheerde identiteit toe te wijzen:

VAN TOEPASSING OP: Azure CLI ml-extensie v2 (huidige)

az ml compute update --name <cluster name> --user-assigned-identities <my-identity-id>

Als u wilt toestaan dat het rekencluster de basisinstallatiekopieën ophaalt, verleent u de ACRPull-rol van de beheerde service-id op de persoonlijke ACR

VAN TOEPASSING OP: Azure CLI ml-extensie v2 (huidige)

az role assignment create --assignee <principal ID> \
--role acrpull \
--scope "/subscriptions/<subscription ID>/resourceGroups/<private ACR resource group>/providers/Microsoft.ContainerRegistry/registries/<private ACR name>"

Maak ten slotte een omgeving en geef de locatie van de basisinstallatiekopieën op in het YAML-bestand van de omgeving.

VAN TOEPASSING OP: Azure CLI ml-extensie v2 (huidige)

$schema: https://azuremlschemas.azureedge.net/latest/environment.schema.json
name: docker-image-example
image: pytorch/pytorch:latest
description: Environment created from a Docker image.

az ml environment create --file <yaml file>

U kunt nu de omgeving in een trainingstaak gebruiken.

Een door Azure Machine Learning beheerde omgeving bouwen in de basisinstallatiekopie van een persoonlijke ACR voor training of deductie

Notitie

Verbinding maken met een persoonlijke ACR met behulp van door de gebruiker toegewezen beheerde identiteit wordt momenteel niet ondersteund. De beheersleutel is het enige verificatietype dat wordt ondersteund voor privé-ACR.

Volgende stappen