Freigeben über


Einrichten der Authentifizierung zwischen Azure Machine Learning und anderen Diensten

GILT FÜR:Azure CLI ML-Erweiterung v2 (aktuell)Python SDK azure-ai-ml v2 (aktuell)

Azure Machine Learning setzt sich aus mehreren Azure-Diensten zusammen. Es gibt mehrere Möglichkeiten, wie die Authentifizierung zwischen Azure Machine Learning und den Diensten, auf denen es basiert, erfolgen kann.

  • Der Azure Machine Learning-Arbeitsbereich verwendet eine verwaltete Identität für die Kommunikation mit anderen Diensten. Standardmäßig ist dies eine systemseitig zugewiesene verwaltete Identität. Sie können stattdessen auch eine benutzerseitig zugewiesene verwaltete Identität verwenden.
  • Azure Machine Learning verwendet Azure Container Registry (ACR), um Docker-Images zu speichern, die zum Trainieren und Bereitstellen von Modellen verwendet werden. Wenn Sie Azure Machine Learning erlauben, ACR automatisch zu erstellen, wird das Administratorkonto aktiviert.
  • Der Azure Machine Learning-Computecluster verwendet eine verwaltete Identität, um Verbindungsinformationen für Datenspeicher aus Azure Key Vault abzurufen und Docker-Images aus ACR zu pullen. Sie können auch einen identitätsbasierten Zugriff auf Datenspeicher konfigurieren, der stattdessen die verwaltete Identität des Computeclusters verwendet.
  • Der Zugriff auf die Daten kann über mehrere Pfade erfolgen, je nach Datenspeicherdienst und Ihrer Konfiguration. Die Authentifizierung beim Datenspeicher kann z. B. einen Kontoschlüssel, ein Token, einen Sicherheitsprinzipal, eine verwaltete Identität oder eine Benutzeridentität verwenden.
  • Verwaltete Onlineendpunkte können eine verwaltete Identität verwenden, um auf Azure-Ressourcen zuzugreifen, wenn ein Rückschluss ausgeführt wird. Weitere Informationen finden Sie unter Zugreifen auf Azure-Ressourcen über einen Onlineendpunkt.

Voraussetzungen

Stellen Sie vor dem Ausführen der Schritte in diesem Artikel sicher, dass Sie über die folgenden erforderlichen Komponenten verfügen:

  • Ein Azure Machine Learning-Arbeitsbereich. Wenn keiner vorliegt, führen Sie die Schritte unter Schnellstart: Erstellen von Arbeitsbereichsressourcen aus, um einen Arbeitsbereich zu erstellen.

  • Die Azure CLI und die ml-Erweiterung oder das Azure Machine Learning Python SDK v2:

    • Informationen zum Installieren der Azure CLI und der Erweiterung finden Sie unter Installieren, Einrichten und Verwenden der CLI (v2).

      Wichtig

      In den CLI-Beispielen in diesem Artikel wird davon ausgegangen, dass Sie die Bash-Shell (oder eine kompatible Shell) verwenden, beispielsweise über ein Linux-System oder ein Windows-Subsystem für Linux.

    • Verwenden Sie zum Installieren des Python SDK v2 den folgenden Befehl:

      pip install azure-ai-ml azure-identity
      

      Verwenden Sie den folgenden Befehl, um eine vorhandene Installation des SDK auf die neueste Version zu aktualisieren:

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

      Weitere Informationen finden Sie unter Installieren des Python SDK v2 für Azure Machine Learning.

  • Zum Zuweisen von Rollen muss die Anmeldung für Ihr Azure-Abonnement die Rolle Operator für verwaltete Identität oder eine andere Rolle aufweisen, die die erforderlichen Aktionen zulässt (z. B. Besitzer).

  • Sie müssen mit dem Erstellen und Arbeiten mit verwalteten Identitäten vertraut sein.

Arbeitsbereichsidentitätstypen

Der Azure Machine Learning-Arbeitsbereich verwendet eine verwaltete Identität für die Kommunikation mit anderen Diensten. Für Azure Machine Learning werden mehrere Identitätstypen unterstützt.

Typ der verwalteten Identität Rollenzuweisungserstellung Zweck
Systemseitig zugewiesen (SAI) Von Microsoft verwaltet Lebenszyklus, der an eine Ressource gebunden ist; Verwendung einzelner Ressourcen; einfacher Einstieg
System-assigned+user-assigned (SAI+UAI) Von Ihnen verwaltet Unabhängiger Lebenszyklus für eine benutzerbasierte Identität, Mehrressourcennutzung, steuert den geringstprivilegierten Zugriff. Zugreifen auf Daten im Trainingsaufträgen

Sobald ein Arbeitsbereich mit dem SAI-Identitätstyp erstellt worden ist, kann er zu SAI+UAI aktualisiert werden, aber nicht zurück von SAI+UAI zu SAI. Sie können demselben Arbeitsbereich mehrere vom benutzerseitig zugewiesene Identitäten zuweisen.

Azure Container Registry und Identitätstypen

In der folgenden Tabelle finden Sie die Unterstützungsmatrix bei der Authentifizierung bei Azure Container Registry abhängig von der Authentifizierungsmethode und der Konfiguration des Zugriffs auf das öffentliche Netzwerk für Azure Container Registry.

Authentifizierungsmethode Öffentlicher Netzwerkzugriff
deaktiviert
Azure Container Registry
Zugriff auf öffentliches Netzwerk aktiviert
Administratorbenutzer
Arbeitsbereich der systemseitig zugewiesenen verwalteten Identität
Benutzerseitig zugewiesene verwaltete Identität des Arbeitsbereichs
mit der ACRPull-Rolle, die der Identität zugewiesen ist

Benutzerseitig zugewiesene verwaltete Identität

Arbeitsbereich

Sie können beim Erstellen eines Azure Machine Learning-Arbeitsbereichs aus dem Azure-Portal eine benutzerseitig zugewiesene verwaltete Identität hinzufügen. Führen Sie beim Erstellen des Arbeitsbereichs die folgenden Schritte aus:

  1. Wählen Sie auf der Seite Grundlagen das Azure Storage-Konto sowie die Azure Container Registry- und Azure Key Vault-Instanz aus, die Sie mit dem Arbeitsbereich verwenden möchten.
  2. Wählen Sie auf der Seite Identität die Option Benutzerseitig zugewiesene Identität und dann die zu verwendende verwaltete Identität aus.

Die folgenden Azure RBAC-Rollenzuweisungen sind für Ihre benutzerseitig zugewiesene verwaltete Identität für Ihren Azure Machine Learning-Arbeitsbereich erforderlich, um auf Daten in den mit dem Arbeitsbereich verbundenen Ressourcen zuzugreifen.

Resource Berechtigung
Azure Machine Learning-Arbeitsbereich Mitwirkender
Azure Storage Mitwirkender (Steuerungsebene) + Mitwirkender an Speicherblobdaten (Datenebene, optional, um die Datenvorschau in Azure Machine Learning Studio zu aktivieren)
Azure Key Vault (bei Verwendung des RBAC-Berechtigungsmodells) Mitwirkender (Steuerungsebene) + Key Vault-Administrator (Datenebene)
Azure Key Vault (bei Verwendung des Berechtigungsmodells für Zugriffsrichtlinien) Mitwirkender + alle Zugriffsrichtlinienberechtigungen außer Bereinigen
Azure Container Registry Mitwirkender
Azure Application Insights Beitragender

Zum automatisierten Erstellen von Rollenzuweisungen für Ihre benutzerseitig zugewiesene verwaltete Identität können Sie diese ARM-Vorlage verwenden.

Tipp

Für einen Arbeitsbereich mit kundenseitig verwalteten Schlüsseln für die Verschlüsselung können Sie eine benutzerseitig zugewiesene verwaltete Identität zur Authentifizierung über den Speicher an Key Vault übergeben. Verwenden Sie die Parameter user-assigned-identity-for-cmk-encryption (CLI) oder user_assigned_identity_for_cmk_encryption (SDK), um die verwaltete Identität zu übergeben. Diese verwaltete Identität kann dieselbe oder eine andere sein als die primäre benutzerseitig zugewiesene verwaltete Identität des Arbeitsbereichs.

Verwenden Sie eine der folgenden Methoden, um einen Arbeitsbereich mit mehreren benutzerseitig zugewiesenen Identitäten zu erstellen:

GILT FÜR Azure CLI-ML-Erweiterung v2 (aktuell)

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

Der Inhalt der Datei workspace_creation_with_multiple_UAIs.yml lautet wie folgt:

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>

Verwenden Sie eine der folgenden Methoden, um benutzerseitig zugewiesene Identitäten für einen Arbeitsbereich zu aktualisieren. Dies umfasst das Hinzufügen neuer Identitäten oder das Löschen vorhandener Identitäten:

GILT FÜR Azure CLI-ML-Erweiterung v2 (aktuell)

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

Der Inhalt der Datei workspace_update_with_multiple_UAIs.yml lautet wie folgt:

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>

Tipp

Um eine neue UAI hinzuzufügen, können Sie die neue UAI-ID unter dem Abschnitt „user_assigned_identities“ zusätzlich zu den vorhandenen UAIs angeben. Es ist erforderlich, alle vorhandenen UAI-IDs zu übergeben.
Um eine oder mehrere vorhandene UAIs zu löschen, können Sie die UAI-IDs, die beibehalten werden sollen, unter dem Abschnitt „user_assigned_identities“ ablegen, die übrigen UAI-IDs werden dann gelöscht.

Hinzufügen einer benutzerseitig zugewiesenen verwalteten Identität zu einem Arbeitsbereich zusätzlich zu einer vom System zugewiesenen Identität

In einigen Szenarien müssen Sie möglicherweise zusätzlich zur standardmäßigen vom System zugewiesenen Arbeitsbereichsidentität eine benutzerseitig zugewiesene verwaltete Identität verwenden. Führen Sie die folgenden Schritte aus, um eine benutzerseitig zugewiesene verwaltete Identität hinzuzufügen, ohne die vorhandene Arbeitsbereichsidentität zu ändern:

  1. Erstellen einer benutzerseitig zugewiesenen verwalteten Identität. Speichern Sie die ID für die verwaltete Identität, die Sie erstellen.

  2. Um die verwaltete Identität an Ihren Arbeitsbereich anzufügen, benötigen Sie eine YAML-Datei, die die Identität angibt. Hier ist ein Beispiel für den Inhalt der YAML-Datei. Ersetzen Sie <TENANT_ID>, <RESOURCE_GROUP> und <USER_MANAGED_ID> durch Ihre Werte.

    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. Verwenden Sie den Azure CLI-Befehl az ml workspace update, um Ihren Arbeitsbereich zu aktualisieren. Geben Sie die YAML-Datei aus dem vorherigen Schritt mithilfe des --file-Parameters an. Das folgende Beispiel zeigt, wie dieser Befehl aussieht:

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

Computecluster

Hinweis

Azure Machine Learning-Computecluster unterstützen nur eine systemseitig zugewiesene Identität oder mehrere benutzerseitig zugewiesene Identitäten, nicht beides gleichzeitig.

Bei der standardmäßigen verwalteten Identität handelt es sich um die systemseitig zugewiesene verwaltete Identität oder die erste benutzerseitig zugewiesene verwaltete Identität.

Während einer Ausführung gibt es zwei Anwendungen einer Identität:

  1. Das System verwendet eine Identität zum Einrichten der Speichereinbindungen, der Containerregistrierung und der Datenspeicher des Benutzers.

    • In diesem Fall verwendet das System die standardmäßig verwaltete Identität.
  2. Sie wenden eine Identität an, um aus dem Code heraus für einen übermittelten Auftrag auf Ressourcen zuzugreifen:

    • Geben Sie in diesem Fall den Wert für client_id entsprechend der verwalteten Identität an, die Sie zum Abrufen von Anmeldeinformationen verwenden möchten.
    • Alternativ können Sie die Client-ID der benutzerseitig zugewiesenen Identität über die Umgebungsvariable DEFAULT_IDENTITY_CLIENT_ID abrufen.

    So rufen Sie beispielsweise ein Token für einen Datenspeicher mit der standardmäßig verwalteten Identität ab:

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

Um einen Computecluster mit verwalteter Identität zu konfigurieren, verwenden Sie eine der folgenden Methoden:

GILT FÜR Azure CLI-ML-Erweiterung v2 (aktuell)

az ml compute create -f create-cluster.yml

Wo der Inhalt von create-cluster.yml Folgendem entspricht:

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

Zum Vergleich: Das folgende Beispiel stammt aus einer YAML-Datei, die einen Cluster erstellt, der eine systemseitig zugewiesene verwaltete Identität verwendet:

$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

Wenn Sie über einen bestehenden Computecluster verfügen, können Sie zwischen benutzer- und systemseitig verwalteter Identität wechseln. In den folgenden Beispielen wird veranschaulicht, wie Sie die Konfiguration ändern:

Benutzerseitig zugewiesene verwaltete Identität

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"

Systemseitig zugewiesene verwaltete Identität

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

Datenspeicher

Wenn Sie einen Datenspeicher erstellen, für den der identitätsbasierte Datenzugriff verwendet wird, wird anhand Ihres Azure-Kontos (Microsoft Entra-Token) überprüft, ob Sie über die Berechtigung für den Zugriff auf den Speicherdienst verfügen. Im Szenario mit identitätsbasiertem Datenzugriff werden keine Anmeldeinformationen für die Authentifizierung gespeichert. Nur die Speicherkontoinformationen werden im Datenspeicher gespeichert.

Im Gegensatz dazu speichern Datenspeicher, die eine auf Anmeldeinformationen basierende Authentifizierung verwenden, Verbindungsinformationen wie Ihren Speicherkontoschlüssel oder Ihr SAS-Token im Schlüsseltresor zwischen, der dem Arbeitsbereich zugeordnet ist. Dieser Ansatz hat die Einschränkung, dass andere Benutzer des Arbeitsbereichs mit ausreichenden Berechtigungen diese Anmeldeinformationen abrufen können, was für einige Unternehmen ein Sicherheitsrisiko darstellen kann.

Weitere Informationen zur Authentifizierung des Zugriffs auf die Daten finden Sie im Artikel Datenverwaltung. Informationen zum Konfigurieren des identitätsbasierten Zugriffs auf Daten finden Sie unter Erstellen von Datenspeichern.

Es gibt zwei Szenarien, in denen Sie den identitätsbasierten Datenzugriff in Azure Machine Learning anwenden können. Diese Szenarien eignen sich gut für den identitätsbasierten Zugriff, wenn Sie mit vertraulichen Daten arbeiten und eine präzisere Datenzugriffsverwaltung benötigen:

  • Zugreifen auf Speicherdienste
  • Machine Learning-Trainingsmodelle

Der identitätsbasierte Zugriff ermöglicht es Ihnen, rollenbasierte Zugriffssteuerungen (RBAC) zu verwenden, um einzuschränken, welche Identitäten (wie Benutzer oder Computeressourcen) Zugriff auf die Daten haben.

Zugreifen auf Speicherdienste

Sie können eine Verbindung mit Speicherdiensten per identitätsbasiertem Zugriff herstellen, indem Sie Azure Machine Learning-Datenspeicher nutzen.

Wenn Sie den identitätsbasierten Datenzugriff nutzen, werden Sie von Azure Machine Learning zum Eingeben Ihres Microsoft Entra-Tokens für die Authentifizierung für den Datenzugriff aufgefordert, anstatt Ihre Anmeldeinformationen im Datenspeicher zu speichern. Dieser Ansatz ermöglicht die Verwaltung des Datenzugriffs auf Speicherebene und sorgt für die Vertraulichkeit der Anmeldeinformationen.

Das gleiche Verhalten gilt, wenn Sie interaktiv mit Daten über ein Jupyter Notebook auf Ihrem lokalen Computer oder einer Compute-Instanz arbeiten.

Hinweis

Bei der Authentifizierung mit Anmeldeinformationen wird Folgendes gespeichert: Abonnement-ID, SAS-Token (Shared Access Signature) und Speicherzugriffsschlüssel sowie Dienstprinzipalinformationen, z. B. Client-IDs und Mandanten-IDs.

Um sicherzustellen, dass eine sichere Verbindung mit Ihrem Speicherdienst in Azure hergestellt wird, müssen Sie für Azure Machine Learning über die Berechtigung zum Zugreifen auf den entsprechenden Datenspeicher verfügen.

Warnung

Mandantenübergreifender Zugriff auf Speicherkonten wird nicht unterstützt. Wenn für Ihr Szenario mandantenübergreifender Zugriff erforderlich ist, wenden Sie sich unter dem Alias amldatasupport@microsoft.com an das Azure Machine Learning-Datensupportteam, um Unterstützung bei einer Lösung mit benutzerdefiniertem Code zu erhalten.

Beim identitätsbasierten Datenzugriff werden nur Verbindungen mit den folgenden Speicherdiensten unterstützt:

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

Für den Zugriff auf diese Speicherdienste benötigen Sie mindestens die Zugriffsberechtigung Leser von Speicherblobdaten für das Speicherkonto. Nur Speicherkontobesitzer können Ihre Zugriffsebene über das Azure-Portal ändern.

Zugreifen auf Daten für Trainingsaufträge auf einer Compute-Instanz mithilfe einer verwalteten Identität

Bestimmte Machine Learning-Szenarien umfassen die Arbeit mit privaten Daten. In solchen Fällen haben wissenschaftliche Fachkräfte für Daten als Microsoft Entra-Benutzer möglicherweise keinen direkten Zugriff auf die Daten. In diesem Szenario kann die verwaltete Identität einer Compute-Instanz für die Authentifizierung des Datenzugriffs verwendet werden. In diesem Szenario kann der Zugriff auf die Daten nur von einer Compute-Instanz oder einem Computecluster für maschinelles Lernen aus erfolgen, die/der einen Trainingsauftrag ausführt. Bei diesem Ansatz erteilt der Administrator der Compute-Instanz oder der vom Computecluster verwalteten Identität entsprechende Berechtigungen vom Typ „Leser von Speicherblobdaten“. Den einzelnen wissenschaftlichen Fachkräften für Daten muss kein Zugriff gewährt werden.

So aktivieren Sie die Authentifizierung mit der verwalteten Identität der Compute-Instanz

  • Erstellen Sie eine Compute-Instanz mit aktivierter verwalteter Identität. Weitere Informationen finden Sie im Abschnitt Computecluster oder für Compute-Instanzen im Abschnitt Zuweisen einer verwalteten Identität.

    Wichtig

    Wenn die Compute-Instanz auch für Herunterfahren im Leerlauf konfiguriert ist, wird die Compute-Instanz nicht aufgrund von Inaktivität heruntergefahren, es sei denn, die verwaltete Identität hat Mitwirkenden-Zugriff auf den Azure Machine Learning-Arbeitsbereich. Weitere Informationen zu Zugriffsberechtigungen finden Sie unter Verwalten des Zugriffs auf einen Azure Machine Learning-Arbeitsbereich.

  • Weisen Sie der verwalteten Identität der Compute-Instanz mindestens die Rolle „Leser von Speicherblobdaten“ für das Speicherkonto zu.

  • Erstellen Sie alle Datenspeicher mit aktivierter identitätsbasierter Authentifizierung. Weitere Informationen finden Sie unter Erstellen von Datenspeichern.

Hinweis

Der Name der erstellten systemseitig verwalteten Identität für die Compute-Instanz oder den Cluster hat in Microsoft Entra ID dieses Format: /workspace-name/computes/compute-name.

Nachdem die identitätsbasierte Authentifizierung aktiviert ist, wird die verwaltete Identität der Compute-Instanz standardmäßig beim Zugriff auf Daten in Ihren Trainingsaufträgen verwendet. Optional können Sie sich mithilfe der im nächsten Abschnitt beschriebenen Schritte mit der Benutzeridentität authentifizieren.

Informationen zum Verwenden der Konfiguration von Azure RBAC für den Speicher finden Sie unter Rollenbasierte Zugriffssteuerungen.

Zugreifen auf Daten für Trainingsaufträge in Computeclustern mithilfe der Benutzeridentität

GILT FÜR Azure CLI-ML-Erweiterung v2 (aktuell)

Beim Training auf Azure Machine Learning-Computeclustern können Sie sich beim Speicher mit Ihrem Microsoft Entra-Benutzertoken authentifizieren.

Mit diesem Authentifizierungsmodus können Sie Folgendes ausführen:

  • Einrichten fein abgestufter Berechtigungen, wobei verschiedene Arbeitsbereichbenutzer Zugriff auf verschiedene Speicherkonten oder Ordner innerhalb von Speicherkonten haben können.
  • Ermöglichen Sie es wissenschaftlichen Fachkräften für Daten, bestehende Zugriffsrechte auf Speichersysteme zu verwenden.
  • Überwachen des Speicherzugriffs, da die Speicherprotokolle zeigen, welche Identitäten zum Zugriff auf Daten verwendet wurden.

Wichtig

Diese Funktionalität weist die folgenden Einschränkungen auf

  • Das Feature wird für Experimente unterstützt, die über die Azure Machine Learning CLI und das Python SDK V2, nicht aber über ML Studio übermittelt werden.
  • Die Benutzeridentität und die durch Compute verwaltete Identität können nicht für die Authentifizierung innerhalb desselben Auftrags verwendet werden.
  • Bei Pipelineaufträgen empfehlen wir, die Benutzeridentität auf der Ebene des einzelnen Schritts festzulegen, der auf einer Compute und nicht auf Ebene der Stammpipeline ausgeführt wird. ( Obwohl die Identitätseinstellung auf der Ebene der Stammpipeline wie auch auf der Ebene des Schritts unterstützt ist, hat die Einstellung auf Schrittebene Vorrang, wenn beide festgelegt sind. Für Pipelines, die Pipelinekomponenten enthalten, muss die Identität jedoch für einzelne Schritte festgelegt werden, die ausgeführt werden. Die auf der Ebene der Stammpipeline oder Pipelinekomponente festgelegte Identität wird nicht funktionieren. Daher empfehlen wir, die Identität der Einfachheit halber auf der Ebene der einzelnen Schritte festzulegen.)

In den folgenden Schritten erfahren Sie, wie Sie den Datenzugriff mithilfe einer Benutzeridentität für Trainingsaufträge für Computecluster über die CLI einrichten können.

  1. Erteilen von Zugriff auf Speicherressourcen für eine Benutzeridentität. Erteilen Sie beispielsweise StorageBlobReader Zugriff auf das bestimmte Speicherkonto, das Sie verwenden möchten, oder erteilen Sie ACL-basierte Berechtigungen für bestimmte Ordner oder Dateien in Azure Data Lake Gen 2-Speicher.

  2. Erstellen Sie einen Azure Machine Learning-Datenspeicher ohne zwischengespeicherte Anmeldeinformationen für das Speicherkonto. Wenn ein Datenspeicher Anmeldeinformationen zwischengespeichert hat, etwa den Speicherkontoschlüssel, werden diese Anmeldeinformationen anstelle der Benutzeridentität verwendet.

  3. Senden Sie einen Trainingsauftrag mit auf type: user_identity festgelegter Eigenschaft identity, wie in der folgenden Auftragsspezifikation dargestellt. Während des Trainingsauftrags erfolgt die Authentifizierung beim Speicher über die Identität des Benutzers, der den Auftrag sendet.

    Hinweis

    Wenn die Eigenschaft identity nicht angegeben wird und der Datenspeicher nicht über zwischengespeicherte Anmeldeinformationen verfügt, wird auf die Compute-verwaltete Identität zurückgegriffen.

    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 den folgenden Schritten erfahren Sie, wie Sie den Datenzugriff mithilfe einer Benutzeridentität für Trainingsaufträge für Computecluster über das Python SDK einrichten können.

  1. Gewähren Sie Datenzugriff, und erstellen Sie einen Datenspeicher, wie zuvor für CLI beschrieben.

  2. Übermitteln Sie einen Trainingsauftrag, bei dem der Identitätsparameter auf azure.ai.ml.UserIdentityConfiguration festgelegt ist. Diese Parametereinstellung ermöglicht dem Auftrag den Zugriff auf Daten im Auftrag des Benutzers, der den Auftrag übermittelt.

    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)
    

Wichtig

Während der Auftragsübermittlung mit aktivierter Authentifizierung mit Benutzeridentität sind die Codemomentaufnahmen durch Prüfsummenüberprüfung vor Manipulationen geschützt. Wenn Sie über vorhandene Pipelinekomponenten verfügen und diese für die Authentifizierung mit aktivierter Benutzeridentität verwenden möchten, müssen Sie sie möglicherweise erneut hochladen. Andernfalls kann der Auftrag während der Prüfsummenüberprüfung fehlschlagen.

Verwenden von virtuellen Netzwerken

Standardmäßig kann Azure Machine Learning nicht mit einem Speicherkonto kommunizieren, das sich hinter einer Firewall oder in einem virtuellen Netzwerk befindet.

Sie können Speicherkonten so konfigurieren, dass der Zugriff nur in bestimmten virtuellen Netzwerken gestattet ist. Diese Konfiguration erfordert zusätzliche Schritte, um sicherzustellen, dass keine Daten außerhalb des Netzwerks kompromittiert wurden. Dieses Verhalten gilt auch für den auf Anmeldeinformationen basierenden Datenzugriff. Weitere Informationen finden Sie unter Verhindern der Datenexfiltration.

Wenn für Ihr Speicherkonto Einstellungen für virtuelle Netzwerke festgelegt wurden, bestimmen diese, welcher Identitätstyp und welche Berechtigungen für den Zugriff erforderlich sind. Beispielsweise legen die Einstellungen des virtuellen Netzwerks für die Datenvorschau und das Datenprofil fest, welcher Identitätstyp zum Authentifizieren des Datenzugriffs verwendet wird.

  • In Szenarien, in denen nur bestimmte IP-Adressen und Subnetze auf den Speicher zugreifen dürfen, verwendet Azure Machine Learning die Arbeitsbereichs-MSI, um Datenvorschauen und -profile zu erstellen.

  • Wenn Sie ADLS Gen 2 oder Blob als Speicher verwenden und dafür Einstellungen für virtuelle Netzwerke festgelegt sind, können Kunden je nach den während der Erstellung definierten Datenspeichereinstellungen entweder die Benutzeridentität oder die Arbeitsbereichs-MSI verwenden.

  • Wenn die Einstellung für das virtuelle Netzwerk „Erlauben Sie Azure-Diensten auf der Liste der vertrauenswürdigen Dienste den Zugriff auf dieses Speicherkonto.“ lautet, wird die Arbeitsbereichs-MSI verwendet.

Szenario: Azure Container Registry ohne Administratorbenutzer

Wenn Sie den Administratorbenutzer für ACR deaktivieren, verwendet Azure Machine Learning eine verwaltete Identität, um Docker-Images zu erstellen und zu pullen. Es gibt zwei Workflows zum Konfigurieren von Azure Machine Learning für die Verwendung von ACR mit deaktiviertem Administratorbenutzer:

  • Gestatten Sie Azure Machine Learning die Erstellung der ACR-Instanz deaktivieren Sie anschließend den Administratorbenutzer.
  • Eine vorhandene ACR-Instanz bereitstellen, bei der der Administratorbenutzer bereits deaktiviert ist.

Azure Machine Learning mit automatisch erstellter ACR-Instanz

  1. Erstellen Sie einen neuen Azure Machine Learning-Arbeitsbereich.

  2. Führen Sie eine Aktion aus, die Azure Container Registry erfordert. Beispiel: Tutorial: Trainieren Ihres ersten Modells.

  3. Rufen Sie den Namen der vom Cluster erstellten ACR-Instanz ab.

    GILT FÜR Azure CLI-ML-Erweiterung v2 (aktuell)

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

    Dieser Befehl gibt einen Wert zurück, der in etwa wie folgt aussieht. Sie benötigen nur den letzten Teil des Texts, d. h. den Namen der ACR-Instanz:

    /subscriptions/<subscription id>/resourceGroups/<my resource group>/providers/MicrosoftContainerReggistry/registries/<ACR instance name>
    
  4. Aktualisieren Sie die ACR, um den Administratorbenutzer zu deaktivieren:

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

Nutzung der eigenen ACR

Wenn der ACR-Administratorbenutzer durch die Abonnementrichtlinie nicht zugelassen ist, sollten Sie zuerst ACR ohne Administratorbenutzer erstellen und es dann dem Arbeitsbereich zuordnen. Erstellen Sie ACR über die Azure CLI, ohne das Argument --admin-enabled festzulegen, oder über das Azure-Portal, ohne den Administratorbenutzer zu aktivieren. Geben Sie dann beim Erstellen des Azure Machine Learning-Arbeitsbereichs die Azure-Ressourcen-ID der ACR an. Das folgende Beispiel veranschaulicht das Erstellen eines neuen Azure Machine Learning-Arbeitsbereichs unter Verwendung einer vorhandenen ACR-Instanz:

GILT FÜR Azure CLI-ML-Erweiterung v2 (aktuell)

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>

Tipp

Um den Wert für den Parameter --container-registry abzurufen, verwenden Sie den Befehl az acr show, um Informationen für Ihre ACR anzuzeigen. Das Feld id enthält die Ressourcen-ID für Ihre ACR.

Wenn Sie bereits über eine vorhandene ACR mit deaktiviertem Administratorbenutzer verfügen, können Sie diese auch an den Arbeitsbereich anfügen, indem Sie sie aktualisieren. Das folgende Beispiel veranschaulicht das Aktualisieren eines Azure Machine Learning-Arbeitsbereichs zur Verwendung einer vorhandenen ACR-Instanz:

GILT FÜR Azure CLI-ML-Erweiterung v2 (aktuell)

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>

Erstellen von Compute mit verwalteter Identität für den Zugriff auf Docker-Images für das Training

Erstellen Sie für den Zugriff auf die ACR des Arbeitsbereichs einen Computecluster für maschinelles Lernen mit aktivierter, vom System zugewiesener verwalteter Identität. Sie können die Identität beim Erstellen der Compute-Instanz über das Azure-Portal oder per Studio aktivieren oder die Azure CLI verwenden, wie im Anschluss gezeigt. Weitere Informationen finden Sie unter Verwenden der verwalteten Identität mit Compute-Clustern.

GILT FÜR Azure CLI-ML-Erweiterung v2 (aktuell)

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

Einer verwalteten Identität wird automatisch die Rolle „ACRPull“ für die ACR des Arbeitsbereichs zugewiesen, um das Pullen von Docker-Images für das Training zu ermöglichen.

Hinweis

Wenn Sie zuerst den Compute erstellen, bevor die ACR des Arbeitsbereichs erstellt wurde, müssen Sie die Rolle „ACRPull“ manuell zuweisen.

Verwenden von Docker-Images für Rückschlüsse

Nachdem Sie ACR ohne Administratorbenutzer (wie oben beschrieben) konfiguriert haben, können Sie ohne Administratorschlüssel von Ihrem Azure Kubernetes-Dienst (AKS) aus auf Docker-Images für Rückschlüsse zugreifen. Wenn Sie AKS erstellen oder an den Arbeitsbereich anhängen, wird dem Dienstprinzipal des Clusters automatisch „ACRPull“-Zugriff auf die ACR des Arbeitsbereichs zugewiesen.

Hinweis

Wenn Sie Ihren eigenen AKS-Cluster bereitstellen, muss für den Cluster anstelle der verwalteten Identität ein Dienstprinzipal aktiviert sein.

Szenario: Verwenden einer privaten Azure Container Registry-Instanz

Azure Machine Learning verwendet standardmäßig Docker-Basisimages, die aus einem von Microsoft verwalteten öffentlichen Repository stammen. Anschließend wird Ihre Trainings- oder Rückschlussumgebung auf diesen Images erstellt. Weitere Informationen finden Sie unter Was sind ML-Umgebungen?

Um ein benutzerdefiniertes Basisimage intern in Ihrem Unternehmen zu verwenden, können Sie verwaltete Identitäten verwenden, um auf Ihre private ACR zuzugreifen. Es gibt zwei Anwendungsfälle:

  • Verwenden Sie das Basisimage für das Training wie besehen.
  • Erstellen Sie ein von Azure Machine Learning verwaltetes Image mit einem benutzerdefinierten Image als Basis.

Pullen Sie das Docker-Basisimage auf den Computecluster für maschinelles Lernen für das Training wie besehen.

Erstellen Sie einen Computecluster für maschinelles Lernen mit aktivierter, vom System zugewiesener verwalteter Identität, wie zuvor beschrieben. Bestimmen Sie dann die Prinzipal-ID der verwalteten Identität.

GILT FÜR Azure CLI-ML-Erweiterung v2 (aktuell)

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

Optional können Sie den Computecluster aktualisieren, um eine vom Benutzer zugewiesene, verwaltete Identität zuzuweisen:

GILT FÜR Azure CLI-ML-Erweiterung v2 (aktuell)

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

Damit der Computecluster die Basisimages pullen kann, gewähren Sie der verwalteten Dienstidentität die Rolle „ACRPull“ für die private ACR.

GILT FÜR Azure CLI-ML-Erweiterung v2 (aktuell)

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

Schließlich erstellen Sie eine Umgebung und geben den Speicherort des Basisimages in der YAML-Datei der Umgebung an.

GILT FÜR Azure CLI-ML-Erweiterung v2 (aktuell)

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

Sie können jetzt die Umgebung in einem Trainingsauftrag verwenden.

Erstellen einer von Azure Machine Learning verwalteten Umgebung in das Basisimage von der privaten ACR für Training oder Rückschluss

Hinweis

Das Herstellen einer Verbindung mit einer privaten ACR mit einer benutzerseitig zugewiesenen verwalteten Identität wird derzeit nicht unterstützt. Der Administratorschlüssel ist der einzige unterstützte Authentifizierungstyp für private ACRs.

Nächste Schritte