Verificatie instellen tussen Azure Machine Learning en andere services

VAN TOEPASSING OP:Azure CLI ml uitbreiding v2 (huidig)Python SDK azure-ai-ml v2 (huidig)

Azure Machine Learning bestaat uit meerdere Azure-services. Meerdere methoden ondersteunen verificatie tussen Azure Machine Learning en de services waarop deze is gebaseerd.

• De Azure Machine Learning-werkruimte maakt gebruik van een beheerde identiteit om te communiceren met andere services. Deze identiteit 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, die gebruikmaakt van de beheerde identiteit van het rekencluster.
• Gegevenstoegang kan plaatsvinden via meerdere paden, afhankelijk van de gegevensopslagservice en uw configuratie. Verificatie voor het gegevensarchief kan bijvoorbeeld gebruikmaken van een accountsleutel, token, beveiligingsprincipaal, beheerde identiteit of gebruikersidentiteit.
• Beheerde online-eindpunten kunnen een beheerde identiteit gebruiken om toegang te krijgen tot Azure-resources bij het uitvoeren van deductie. Zie Toegang tot Azure-resources vanaf een online-eindpunt voor meer informatie.

Vereiste voorwaarden

• Een Azure Machine Learning-werkruimte. Zie De werkruimte maken voor instructies voor het maken van een werkruimte.

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

  • Azure-CLI
  • Python SDK

  Zie ml om de Azure CLI en de extensie te installeren.

  In de voorbeelden in dit artikel wordt ervan uitgegaan dat u een Bash-shell of een compatibele shell gebruikt. U kunt bijvoorbeeld een shell gebruiken op een Linux-systeem of Windows-subsysteem voor Linux.

• 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. Azure Machine Learning ondersteunt meerdere identiteitstypen.

Nadat u een werkruimte hebt gemaakt met het type SAI-identiteit, kunt u deze bijwerken naar SAI+UAI. U kunt een werkruimte van SAI+UAI niet bijwerken naar SAI. U kunt meerdere door de gebruiker toegewezen identiteiten toewijzen aan dezelfde werkruimte.

Door de gebruiker toegewezen beheerde identiteit

Werkruimte

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.

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

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

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

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>

from azure.ai.ml import MLClient, load_workspace
from azure.identity import DefaultAzureCredential

sub_id="<subscription ID>"
rg_name="<resource group name>"
ws_name="<workspace name>"

client = MLClient(DefaultAzureCredential(), sub_id, rg_name)
wps = load_workspace("workspace_creation_with_multiple_UAIs.yml")

workspace = client.workspaces.begin_create(workspace=wps).result()

Als u door de gebruiker toegewezen identiteiten voor een werkruimte wilt bijwerken, inclusief het toevoegen van een nieuwe identiteit of het verwijderen van de bestaande identiteiten, gebruikt u een van de volgende methoden:

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

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>

from azure.ai.ml import MLClient, load_workspace
from azure.identity import DefaultAzureCredential

sub_id="<subscription ID>"
rg_name="<resource group name>"
ws_name="<workspace name>"

client = MLClient(DefaultAzureCredential(), sub_id, rg_name)
wps = load_workspace("workspace_update_with_multiple_UAIs.yml")

workspace = client.workspaces.begin_update(workspace=wps).result()

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-identiteit. 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 de 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, maakt u een YAML-bestand dat de identiteit aangeeft. In het volgende voorbeeld ziet u de inhoud van het YAML-bestand. Vervang de tijdelijke aanduidingen <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 uit de vorige stap op 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
   

Gegevensisolatie voor gedeelde resources

Wanneer meerdere werkruimten dezelfde gekoppelde resources delen (opslagaccount, sleutelkluis of containerregister), schakelt u gegevensisolatie in om naamconflicten te voorkomen en ervoor te zorgen dat elke werkruimte alleen toegang heeft tot zijn eigen gegevens. Met de enableDataIsolation vlag wordt geconfigureerd hoe werkruimte-artefacten worden opgeslagen en geopend in gedeelde resources.

Effecten van het inschakelen van gegevensisolatie

Wanneer u gegevensisolatie inschakelt, past de werkruimte de volgende configuraties toe:

Standaardgedrag op type werkruimte

De standaardwaarde voor gegevensisolatie is afhankelijk van het type werkruimte:

Wanneer gegevensisolatie inschakelen

Gegevensisolatie inschakelen wanneer:

• Meerdere werkruimten delen hetzelfde opslagaccount, de sleutelkluis of het containerregister
• Je moet naamconflicten voorkomen voor artefacten (zoals Docker images of secrets) die met dezelfde naam in werkruimten zijn gemaakt.
• U hebt strenger toegangsbeheer nodig om ervoor te zorgen dat werkruimte-id's alleen toegang hebben tot hun eigen gegevens

Voor hub- en projectwerkruimten is gegevensisolatie standaard ingeschakeld ter ondersteuning van het gedeelde resourcemodel. Zie Wat is een Azure Machine Learning-hubwerkruimte voor meer informatie?

Gegevensisolatie inschakelen bij het maken van een werkruimte

az ml workspace create --name <WORKSPACE_NAME> \
    --resource-group <RESOURCE_GROUP> \
    --enable-data-isolation

$schema: https://azuremlschemas.azureedge.net/latest/workspace.schema.json
name: my-workspace
location: eastus
enable_data_isolation: true
storage_account: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Storage/storageAccounts/<STORAGE_ACCOUNT>
key_vault: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.KeyVault/vaults/<KEY_VAULT>
container_registry: /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.ContainerRegistry/registries/<CONTAINER_REGISTRY>

az ml workspace create --file workspace.yml --resource-group <RESOURCE_GROUP>

from azure.ai.ml import MLClient
from azure.ai.ml.entities import Workspace
from azure.identity import DefaultAzureCredential

# Replace with your Azure subscription and resource group
subscription_id = "<SUBSCRIPTION_ID>"
resource_group = "<RESOURCE_GROUP>"

credential = DefaultAzureCredential()
ml_client = MLClient(credential, subscription_id, resource_group)

workspace = Workspace(
    name="my-workspace",
    location="eastus",
    enable_data_isolation=True,
    storage_account="/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Storage/storageAccounts/<STORAGE_ACCOUNT>",
    key_vault="/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.KeyVault/vaults/<KEY_VAULT>",
    container_registry="/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.ContainerRegistry/registries/<CONTAINER_REGISTRY>"
)

ml_client.workspaces.begin_create(workspace).result()

Rekencluster

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

Tijdens een run heeft een identiteit twee toepassingen.

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:

az ml compute create -f create-cluster.yml

$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"

$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

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"

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

from azure.ai.ml.entities import ManagedIdentityConfiguration, IdentityConfiguration, AmlCompute
from azure.ai.ml.constants import ManagedServiceIdentityType

# Create an identity configuration from the user-assigned managed identity
managed_identity = ManagedIdentityConfiguration(resource_id="/subscriptions/<subscription_id>/resourcegroups/<resource_group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity>")
identity_config = IdentityConfiguration(type = ManagedServiceIdentityType.USER_ASSIGNED, user_assigned_identities=[managed_identity])

# specify aml compute name.
cpu_compute_target = "cpu-cluster"

try:
    ml_client.compute.get(cpu_compute_target)
except Exception:
    print("Creating a new cpu compute target...")
    # Pass the identity configuration
    compute = AmlCompute(
        name=cpu_compute_target, size="STANDARD_D2_V2", min_instances=0, max_instances=4, identity=identity_config
    )
    ml_client.compute.begin_create_or_update(compute)

Kubernetes-cluster berekenen

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

Tijdens een run heeft een identiteit twee toepassingen.

• 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.

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

  • In het geval van Kubernetes-cluster berekenen, moet het ManagedIdentityCredential-object zonder client_id worden opgegeven.

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

  credential = ManagedIdentityCredential()
  token = credential.get_token('https://storage.azure.com/')
  

Als u een Kubernetes-cluster wilt configureren, moet u ervoor zorgen dat de benodigde AML-extensie erin is geïmplementeerd en volgt u de documentatie over het koppelen van de Kubernetes-cluster compute aan uw AML-werkruimte.

Gegevensopslag

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

In tegenstelling daarmee slaan gegevensarchieven die gebruikmaken van op referenties gebaseerde authenticatie verbindingsgegevens in de cache op, zoals uw opslagaccount sleutel of SAS-token, 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.

In twee scenario's kunt u op identiteit gebaseerde gegevenstoegang 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 behulp van 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 met behulp van 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.

Als u veilig verbinding wilt maken met uw opslagservice in Azure, moet u voor Azure Machine Learning toegang hebben tot de bijbehorende gegevensopslag.

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

• Azure Blob Storage (opslagdienst van Azure)
• Azure Data Lake Storage Gen1
• Azure Data Lake Storage Gen2

Als u toegang wilt krijgen tot deze opslagservices, moet u ten minste opslagblobgegevenslezer toegang hebben 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 gebruikt u de beheerde identiteit van een berekening voor verificatie van gegevenstoegang. U hebt alleen toegang tot de gegevens van een rekenproces of een machine learning-rekencluster dat een trainingstaak uitvoert. Met deze methode verleent de beheerder de rekeninstantie of de beheerde identiteit van de rekencluster lezer van opslagblobgegevensrechten. 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 u het rekenproces configureert voor niet-actief afsluiten, 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.

• Geef een beheerde identiteitsinstelling voor rekenkracht minstens de rol van opslagblobgegevenslezer op het opslag-account.

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

Zodra u verificatie op basis van identiteit hebt ingeschakeld, wordt de beheerde computeridentiteit standaard gebruikt bij het openen van gegevens tijdens uw trainingstaken. U kunt zich desgewenst verifiëren met behulp van gebruikersidentiteit door de stappen te volgen die in de volgende sectie worden beschreven.

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 (actueel)

Wanneer u traint op Azure Machine Learning-rekenclusters, kunt u zich verifiëren bij opslag met behulp van 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.

Als u gegevenstoegang wilt instellen met behulp van gebruikersidentiteit voor trainingstaken op rekenclusters vanuit CLI, voert u de volgende stappen uit:

1. Verleen de gebruikersidentiteit toegang tot opslagmiddelen. 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-datastore zonder gecachte referenties 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.

   Opmerking

   Als u de identiteitseigenschap niet opgeeft en het gegevensarchief geen in de cache opgeslagen referenties heeft, gebruikt het systeem een beheerderidentiteit voor compute als back-up.

   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
   

Als u gegevenstoegang wilt instellen met behulp van gebruikersidentiteit voor trainingstaken op rekenclusters vanuit de Python SDK, voert u de volgende stappen uit:

1. Gegevenstoegang verlenen en gegevensopslag maken zoals eerder 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)
   

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 virtueel netwerk heeft, bepalen deze instellingen welk identiteitstype en welke machtigingen toegang nodig is. Voor voorbeeldgegevens en gegevensprofiel bepalen de instellingen van het virtuele netwerk bijvoorbeeld 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, kunt u de gebruikersidentiteit of werkruimte-MSI gebruiken, afhankelijk van de gegevensopslaginstellingen die tijdens het maken zijn gedefinieerd.

• Als de instelling voor het virtuele netwerk Azure-services in de lijst met vertrouwde services toestaat voor toegang tot dit opslagaccount, 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 mee waarvan de beheerder al is uitgeschakeld.

Azure Machine Learning met automatisch aangemaakte ACR-instance

1. Maak een nieuwe Azure Machine Learning-werkruimte.

2. Voer een actie uit waarvoor Azure Container Registry is vereist. Zie 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 (actueel)

   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
   

Neem je eigen ACR mee

Als het abonnementsbeleid de ACR-beheerdergebruiker niet toe staat, maakt u eerst ACR zonder beheerdersgebruiker en koppelt u deze vervolgens aan de werkruimte. Maak ACR vanuit Azure CLI zonder het --admin-enabled argument in te stellen of vanuit De Azure-portal zonder beheerdersgebruiker in te schakelen. Geef bij het maken van de Azure Machine Learning-werkruimte 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 (actueel)

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>

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 (actueel)

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 volgende opdracht. Zie het gebruik van beheerde identiteiten met rekenclusters voor meer informatie.

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

    from azure.ai.ml.entities import IdentityConfiguration, AmlCompute
    from azure.ai.ml.constants import ManagedServiceIdentityType
    
    # Create an identity configuration for a system-assigned managed identity
    identity_config = IdentityConfiguration(type = ManagedServiceIdentityType.SYSTEM_ASSIGNED)
    
    # specify aml compute name.
    cpu_compute_target = "cpu-cluster"
    
    try:
        ml_client.compute.get(cpu_compute_target)
    except Exception:
        print("Creating a new cpu compute target...")
        # Pass the identity configuration
        compute = AmlCompute(
            name=cpu_compute_target, size="STANDARD_D2_V2", min_instances=0, max_instances=4, identity=identity_config
        )
        ml_client.compute.begin_create_or_update(compute)

Een beheerde identiteit krijgt automatisch de ACRPull-rol toegewezen op de ACR van de werkruimte om Docker-images voor training mogelijk te maken.

Docker-installatiekopieën gebruiken voor deductie

Nadat u ACR hebt geconfigureerd zonder beheerdersgebruiker zoals eerder beschreven, hebt u toegang tot Docker-afbeeldingen voor inference zonder beheerderssleutels vanuit uw Azure Kubernetes-service (AKS). Wanneer u AKS maakt of koppelt aan de werkomgeving, krijgt de service-principal van het cluster automatisch ACRPull-toegang tot de ACR van de werkomgeving.

Scenario: Een privé-Azure Container Registry gebruiken

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

Als u een aangepaste basisimage binnen uw onderneming wilt gebruiken, gebruikt u beheerde identiteiten om toegang te krijgen tot uw privé ACR.

1. 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 (actueel)

   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 (actueel)

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

2. Als u wilt toestaan dat het rekencluster de basisinstallatiekopieën ophaalt, verleent u de beheerde service-identiteit (voor de werkruimte of compute) ACRPull-rol op de persoonlijke ACR

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

   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>"
   

3. Maak een omgeving en specificeer de locatie van de basisimage in het omgeving YAML-bestand. Het volgende YAML-bestand laat zien hoe u een omgeving definieert die verwijst naar de persoonlijke ACR. Vervang de <acr-url> door de URL van uw persoonlijke ACR, zoals myregistry.azurecr.io. Vervang het <image-path> met het pad naar uw afbeelding in de persoonlijke ACR, zoals pytorch/pytorch:latest:

   $schema: https://azuremlschemas.azureedge.net/latest/environment.schema.json
   name: docker-image-example
   image: <acr-url>/<image-path>:latest
   description: Environment created from a Docker image.
   

4. De volgende opdracht laat zien hoe u de omgeving maakt op basis van het YAML-bestand. Vervang <yaml file> door het pad naar uw YAML-bestand:

   az ml environment create --file <yaml file>
   

   U kunt nu de omgeving in een trainingstaak gebruiken.

Verwante artikelen

• Meer informatie over bedrijfsbeveiliging in Azure Machine Learning.
• Meer informatie over gegevensbeheer.
• Meer informatie over beheerde identiteiten in het rekencluster.