Azure Machine Learning とその他のサービス間の認証を設定する

適用対象:Azure CLI ml extension v2 (現行)Python SDK azure-ai-ml v2 (現行)

Azure Machine Learning は、複数の Azure サービスで構成されています。 Azure Machine Learning とそれが依存するサービスの間で認証を行う方法は複数あります。

  • Azure Machine Learning ワークスペースでは、マネージド ID を使用して他のサービスと通信します。 既定ではこれは、システム割り当てマネージド ID です。 代わりにユーザー割り当てマネージド ID を使用することもできます。
  • Azure Machine Learning では、Azure Container Registry (ACR) を使用して、モデルのトレーニングとデプロイに使用される Docker イメージを保存します。 Azure Machine Learning で ACR の自動作成を許可すると、管理者アカウントが有効になります。
  • Azure Machine Learning コンピューティング クラスターでは、マネージド ID を使用して Azure Key Vault からデータストアの接続情報を取得し、ACR から Docker イメージをプルします。 また、代わりにコンピューティング クラスターのマネージド ID を使用する、データストアへの ID ベースのアクセスを構成することもできます。
  • データ アクセスは、データ ストレージ サービスと構成に応じて、複数のパスで発生する可能性があります。 たとえば、データストアへの認証では、アカウント キー、トークン、セキュリティ プリンシパル、マネージド ID、ユーザー ID のいずれかを使用できます。
  • マネージド オンライン エンドポイントでは、推論の実行時にマネージド ID を使用して Azure リソースにアクセスできます。 詳細については、「オンライン エンドポイントから Azure リソースにアクセスする」を参照してください。

前提条件

この記事の手順に従う前に、次の前提条件が満たされていることをご確認ください。

  • ロールを割り当てるには、Azure サブスクリプションのログインにマネージド ID オペレーター ロール、または必要なアクション (所有者など) を付与するその他のロールが含まれている必要があります。

  • マネージド ID の作成と操作に慣れている必要があります。

Azure Container Registry でサポートされている構成

次の表は、認証方法とパブリック ネットワーク アクセス ワークスペース フラグに応じて、Azure Container Registry に対して認証するときにサポートされる構成の一覧です。

認証方法 パブリック ネットワーク アクセス
は無効
パブリック ネットワーク アクセス
は有効
管理者ユーザー
ワークスペースのシステム割り当てマネージド ID
ACRPull ロールが ID に割り当てられている
ワークスペースのシステム割り当ておよびユーザー割り当てマネージド ID
ACRPull ロールが ID に割り当てられている
コンピューティング システム割り当てまたはユーザー割り当てマネージド ID

ユーザー割り当てマネージド ID

ワークスペース

Azure portal から Azure Machine Learning ワークスペースを作成するときに、ユーザー割り当てマネージド ID を追加できます。 ワークスペースを作成する際は、次の手順に従います。

  1. [基本] ページで、ワークスペースで使用する Azure Storage アカウント、Azure Container Registry、Azure Key Vault を選びます。
  2. [ID] ページで、[ユーザー割り当て ID] を選び、使用するマネージド ID を選んでください。

Azure Machine Learning ワークスペースがワークスペースに関連するリソースのデータにアクセスするには、ユーザー割り当てマネージド ID に次の Azure RBAC のロールの割り当てが必要になります。

リソース 権限
Azure Machine Learning ワークスペース Contributor
Azure Storage 共同作成者 (コントロール プレーン) + ストレージ BLOB データ共同作成者 (データ プレーン、省略可能、Azure Machine Learning スタジオでデータのプレビューを有効にするため)
Azure Key Vault (RBAC アクセス許可モデルを使用する場合) 共同作成者 (コントロール プレーン) + Key Vault 管理者 (データ プレーン)
Azure Key Vault (アクセス ポリシーのアクセス許可モデルを使用する場合) 共同作成者 + 消去操作以外のすべてのアクセス ポリシーのアクセス許可
Azure Container Registry Contributor
Azure Application Insights 共同作成者

ユーザー割り当てマネージド ID でロールの割り当てを自動的に作成するには、この ARM テンプレートを使用できます。

ヒント

暗号化のためのカスタマー マネージド キーを持つワークスペースの場合、ストレージから Key Vault への認証のために、ユーザーに割り当てられたマネージド ID を渡すことができます。 user-assigned-identity-for-cmk-encryption (CLI) または user_assigned_identity_for_cmk_encryption (SDK) の各パラメーターを使用して、マネージド ID を渡します。 このマネージド ID は、ワークスペースのプライマリ ユーザー割り当てのマネージド ID と同じであることも異なることもあります。

複数のユーザー割り当て ID を持つワークスペースを作成するには、次のいずれかの方法を使用します。

適用対象: Azure CLI ML 拡張機能 v2 (現行)

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

workspace_creation_with_multiple_UAIs.yml の内容は、次のようになります。

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>

ワークスペースのユーザー割り当て ID を更新し、新しい ID の追加や既存の ID の削除を含める場合は、次のいずれかの方法を使用します。

適用対象: Azure CLI ML 拡張機能 v2 (現行)

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

workspace_update_with_multiple_UAIs.yml の内容は、次のようになります。

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>

ヒント

新しい UAI を追加するには、既存の UAI に加えて、セクション user_assigned_identities の下に新しい UAI ID を指定できます。既存のすべての UAI ID を渡す必要があります。
既存の UAI を 1 つ以上削除するには、セクション user_assigned_identities の下に保持する必要がある UAI ID を配置できます。そうすると、残りの UAI ID が削除されます。
ID の種類を SAI から UAI|SAI に更新するには、種類を "user_assigned" から "system_assigned, user_assigned" に変更できます。

コンピューティング クラスター

Note

Azure Machine Learning コンピューティング クラスターは、システムによって割り当てられた 1 つの ID またはユーザーによって割り当てられた複数の ID のみをサポートします。両方同時にはサポートしません。

既定のマネージド ID は、システムによって割り当てられたマネージド ID、またはユーザーが割り当てた最初のマネージドID です。

実行中、ID は次の 2 つの方法で利用されます。

  1. ユーザーのストレージ マウント、コンテナー レジストリ、データストアを設定するために、システムによって ID が使用されます。

    • この場合、システムは既定のマネージド ID を使用します。
  2. 送信されたジョブのコード内からリソースにアクセスするために ID を適用します。

    • この場合、資格情報の取得に使用するマネージド ID に対応する client_id を指定します。
    • または、DEFAULT_IDENTITY_CLIENT_ID 環境変数を使用して、ユーザーが割り当てた ID のクライアント ID を取得します。

    たとえば、既定のマネージド ID を使用してデータストアのトークンを取得するには、次のようにします。

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

マネージド ID を使用してコンピューティング クラスターを構成するには、次のいずれかの方法を使用します。

適用対象: Azure CLI ML 拡張機能 v2 (現行)

az ml compute create -f create-cluster.yml

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"

比較のために、次の例は、システム割り当てマネージド ID を使用するクラスターを作成する YAML ファイルからのものです。

$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

既存のコンピューティング クラスターがある場合は、ユーザー マネージド ID とシステム マネージド ID の間で変更できます。 次の例は、構成を変更する方法を示しています。

ユーザー割り当てマネージド ID

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"

システム割り当てマネージド 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

データ ストレージ

ID ベースのデータ アクセスを使用するデータストアを作成するときは、Azure アカウント (Microsoft Entra トークン) を使用して、ストレージ サービスにアクセスするためのアクセス許可があることが確認されます。 ID ベースのデータ アクセスのシナリオでは、認証の資格情報が保存されません。 ストレージ アカウント情報のみがデータストアに格納されます。

これに対し、資格情報ベースの認証を使用するデータストアは、接続情報 (ストレージ アカウント キーや SAS トークンなど) を、ワークスペースに関連付けられているキー コンテナーにキャッシュします。 この方法には、十分なアクセス許可を持つ他のワークスペース ユーザーがそれらの資格情報を取得する可能性があるという制限事項があります。これは、組織によってはセキュリティ上の問題になる可能性があります。

データ アクセスの認証方法の詳細については、「データ管理」を参照してください。 データへの ID ベースのアクセスの構成については、「データストアの作成」を参照してください。

Azure Machine Learning で ID ベースのデータ アクセスを適用できるシナリオは 2 つあります。 これらのシナリオは、機密データを扱っていて、より詳細なデータ アクセス管理が必要な場合の ID ベースのアクセスに適しています。

  • ストレージ サービスへのアクセス
  • 機械学習トレーニング モデル

ID ベースのアクセスを使用すると、ロールベースのアクセス制御 (RBAC) を使用して、データにアクセスできる ID (ユーザーやコンピューティング リソースなど) を制限できます。

ストレージ サービスへのアクセス

Azure Machine Learning データストアを使用した ID ベースのデータ アクセスを使用してストレージ サービスに接続できます。

ID ベースのデータ アクセスを使用すると、データストアに資格情報を保持する代わりに、Azure Machine Learning によって、データ アクセス認証用の Microsoft Entra トークンの入力が求められます。 このアプローチにより、ストレージ レベルでのデータ アクセス管理が可能になり、資格情報が機密として保持されます。

ローカル コンピューターまたはコンピューティング インスタンスで Jupyter Notebook を使用して対話形式でデータを操作する場合、同じ動作が当てはまります。

注意

資格情報ベースの認証を使用して格納される資格情報には、サブスクリプション ID、Shared Access Signature (SAS) トークン、ストレージ アクセス キー、サービス プリンシパル情報 (クライアント ID やテナント ID など) が含まれます。

Azure 上のストレージ サービスに安全に接続できるようにするには、Azure Machine Learning では、対応するデータ ストレージにアクセスするためのアクセス許可が必要です。

警告

ストレージ アカウントへのクロス テナント アクセスはサポートされていません。 シナリオでクロス テナント アクセスが必要な場合、Azure Machine Learning データ サポート チームにメール amldatasupport@microsoft.com で連絡し、カスタム コード解決を要請してください。

ID ベースのデータ アクセスでは、次のストレージ サービスのみへの接続がサポートされます。

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

これらのストレージ サービスにアクセスするには、少なくともストレージ BLOB データ閲覧者としての、ストレージ アカウントへのアクセス権が必要です。 Azure portal を使用してアクセス レベルを変更できるのは、ストレージ アカウントの所有者だけです。

マネージド ID を使用してコンピューティングでのトレーニング ジョブにおけるデータにアクセスする

特定の機械学習のシナリオには、プライベート データの操作が含まれます。 このような場合、データ サイエンティストは Microsoft Entra ユーザーとしてデータに直接アクセスできない可能性があります。 このシナリオでは、コンピューティングのマネージド ID がデータ アクセス認証に使用できます。 このシナリオでは、トレーニング ジョブを実行しているコンピューティング インスタンスまたは機械学習コンピューティング クラスターからのみデータにアクセスできます。 この方法では、管理者はストレージでコンピューティング インスタンスまたはコンピューティング クラスターにマネージド ID ストレージ BLOB データ閲覧者のアクセス許可を付与します。 個々のデータ サイエンティストにアクセス権を付与する必要はありません。

コンピューティング マネージド ID を使用して認証を有効にする方法は次のとおりです。

  • マネージド ID が有効になっているコンピューティングを作成します。 「コンピューティング クラスター」のセクション、またはコンピューティング インスタンスについては、「マネージド ID の割り当て」セクションを参照してください。

    重要

    コンピューティング インスタンスもアイドル シャットダウン用に構成されている場合、マネージド ID に Azure Machine Learning ワークスペースへの共同作成者アクセス権がない限り、非アクティブのためコンピューティング インスタンスは シャットダウン されません。 アクセス許可割り当ての詳細については、「Azure Machine Learning ワークスペースへのアクセスの管理」を参照してください。

  • ストレージ アカウントの、少なくともストレージ BLOB データ閲覧者ロールをコンピューティング マネージド ID に付与します。

  • ID ベースの認証が有効になっているデータストアを作成します。 「データストアを作成する」を参照してください。

Note

コンピューティング インスタンスやクラスターに作成されたシステム マネージド ID の名前は、お使いの Microsoft Entra ID 内では /workspace-name/computes/compute-name の形式になります。

ID ベースの認証が有効になると、トレーニング ジョブ内のデータにアクセスするときに、コンピューティング マネージド ID が既定で使用されます。 必要に応じて、次のセクションで説明する手順を使用すれば、ユーザー ID での認証ができます。

ストレージに対する Azure RBAC の構成の使用については、ロールベースのアクセス制御に関するページを参照してください。

ユーザー ID を使用してコンピューティング クラスターのトレーニング ジョブのデータにアクセスする

適用対象: Azure CLI ML 拡張機能 v2 (現行)

Azure Machine Learning コンピューティング クラスターでトレーニングを行うときは、ユーザーの Microsoft Entra トークンを使用してストレージに対する認証を行うことができます。

この認証モードでは、次のことができます。

  • さまざまなワークスペース ユーザーがストレージ アカウント内の異なるストレージ アカウントまたはフォルダーにアクセスできるように、アクセス許可を細かく設定します。
  • データ サイエンティストがストレージ システムで既存のアクセス許可を再利用できるようにします。
  • ストレージ ログには、データへのアクセスに使用された ID が表示されるため、ストレージ アクセスを監査できます。

重要

この機能には、次の制限があります

  • この機能は Azure Machine Learning CLI と Python SDK V2 を介して送信された実験ではサポートされますが、ML Studio 経由ではサポートされません。
  • ユーザー ID とコンピューティング マネージド ID は、同じジョブ内の認証には使用できません
  • パイプライン ジョブの場合は、ルート パイプライン レベルではなく、コンピューティングで実行される個々のステップ レベルでユーザー ID を設定することをお勧めします (ID 設定はルート パイプラインとステップの両方のレベルでサポートされていますが、両方が設定されている場合は、ステップ レベルの設定が優先されます。ただし、パイプライン コンポーネントを含むパイプラインの場合は、実行される個々のステップで ID を設定する必要があります。ルート パイプラインまたはパイプライン コンポーネント レベルで設定された ID は機能しません。そのため、わかりやすくするために、個々のステップ レベルで ID を設定することをお勧めします)。

次の手順では、CLI からコンピューティング クラスターでのトレーニング ジョブにユーザー ID に基づくデータ アクセスを設定する方法について説明します。

  1. ストレージ リソースへのアクセス権をユーザー ID に付与します。 たとえば、使用する特定のストレージ アカウントに StorageBlobReader アクセス権を付与するか、Azure Data Lake Gen 2 ストレージ内の特定のフォルダーまたはファイルに ACL ベースのアクセス許可を付与します。

  2. ストレージ アカウントの資格情報をキャッシュせずに、Azure Machine Learning データストアを作成します。 データストアにストレージ アカウント キーなどの資格情報がキャッシュされる場合、それらの資格情報がユーザー ID の代わりに使用されます。

  3. 次のジョブの仕様に示すように、プロパティ identitytype: user_identity に設定されたトレーニング ジョブを送信します。 トレーニング ジョブ中、ストレージへの認証は、ジョブを送信するユーザーの ID を介して行われます。

    注意

    identity プロパティが指定されないままで、データストアに資格情報がキャッシュされていない場合は、コンピューティング マネージド ID がフォールバック オプションになります。

    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
    

次の手順では、Python SDK からコンピューティング クラスターでのトレーニング ジョブにユーザー ID に基づくデータ アクセスを設定する方法について説明します。

  1. CLI について前述したように、データ アクセスを許可し、データ ストアを作成します。

  2. ID パラメーターを azure.ai.ml.UserIdentityConfiguration に設定してトレーニング ジョブを送信します。 このパラメーター設定を使用すると、ジョブを送信するユーザーに代わって、ジョブがデータにアクセスできるようになります。

    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)
    

重要

ユーザー ID を有効にした認証を使用したジョブの送信中、コード スナップショットはチェックサム検証によって改ざんから保護されます。 既存のパイプライン コンポーネントがあり、ユーザー ID を有効にした認証で使用する場合は、再びアップロードが必要になる場合があります。 そうしないと、チェックサムの検証中にジョブが失敗する可能性があります。

仮想ネットワークの使用

既定では、Azure Machine Learning は、ファイアウォールの内側または仮想ネットワーク内にあるストレージ アカウントとは通信できません。

特定の仮想ネットワークからのアクセスのみを許可するように、ストレージ アカウントを構成できます。 この構成では、データがネットワークの外に漏洩しないようにするための追加の手順が必要になります。 この動作は、資格情報ベースのデータ アクセスの場合と同じです。 詳細については、データ流出の防止方法に関する記事を参照してください。

ストレージ アカウントに仮想ネットワークの設定がある場合は、必要な ID の種類とアクセス許可が決まります。 たとえば、データのプレビューとプロファイルの場合は、仮想ネットワークの設定によって、データアクセスの認証に使用される ID の種類が決まります。

  • 特定の IP とサブネットのみに、ストレージへのアクセスが許可されている場合は、Azure Machine Learning がワークスペース MSI を使用して、データのプレビューとプロファイルを実行します。

  • ストレージが ADLS Gen 2 または Blob であり、仮想ネットワークの設定がある場合は、作成時に定義されたデータストアの設定に応じて、お客様が、ユーザー ID またはワークスペース MSI を使用できます。

  • 仮想ネットワークの設定が "信頼されたサービスの一覧にある Azure サービスからこのストレージ アカウントにアクセスできる" である場合は、ワークスペース MSI が使用されます。

シナリオ: 管理者ユーザーなしの Azure Container Registry

ACR の管理者ユーザーを無効にすると、Azure Machine Learning はマネージド ID を使用して Docker イメージのビルドおよびプルが行われます。 管理者ユーザーが無効になっている ACR を使用するように Azure Machine Learning を構成する場合、次の 2 つのワークフローがあります。

  • Azure Machine Learning で ACR インスタンスを作成できるようにしてから、管理者ユーザーを無効にします。
  • 管理者ユーザーが既に無効になっている既存の ACR を使用します。

自動作成された ACR インスタンスを使用する Azure Machine Learning

  1. 新しい Azure Machine Learning ワークスペースを作成します。

  2. Azure Container Registry を必要とするアクションを実行します。 「チュートリアル: 最初のモデルをトレーニングする」はその例です。

  3. クラスターによって作成された ACR の名前を取得します。

    適用対象: Azure CLI ML 拡張機能 v2 (現行)

    az ml workspace show -w <my workspace> \
    -g <my resource group>
    --query containerRegistry
    

    このコマンドにより、次のテキストのような値が返されます。 テキストの最後の部分 (ACR インスタンス名) のみが必要です。

    /subscriptions/<subscription id>/resourceGroups/<my resource group>/providers/MicrosoftContainerReggistry/registries/<ACR instance name>
    
  4. ACR を更新して、管理者ユーザーを無効にします。

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

独自の ACR を使用する

ACR 管理者ユーザーがサブスクリプション ポリシーによって禁止されている場合は、まず管理者ユーザーなしで ACR を作成し、それをワークスペースに関連付けます。 また、管理者ユーザーが無効になっている既存の ACR がある場合は、それをワークスペースにアタッチすることもできます。

--admin-enabled 引数を設定せずに Azure CLI から ACR を作成するか、管理者ユーザーを有効にせずに Azure portal から ACR を作成します。 次に、Azure Machine Learning ワークスペースを作成するときに、ACR の Azure リソース ID を指定します。 次の例は、既存の ACR を使用する新しい Azure Machine Learning ワークスペースを作成する方法を示しています。

ヒント

--container-registry パラメーターの値を取得するには、az acr show コマンドを使用して ACR の情報を表示します。 id フィールドに、ACR のリソース ID が表示されます。

適用対象: Azure CLI ML 拡張機能 v2 (現行)

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

マネージド ID 付きのコンピューティングを作成し、トレーニング用の Docker イメージにアクセスする

ワークスペース ACR にアクセスするには、システム割り当てマネージド ID が有効になっている機械学習コンピューティング クラスターを作成します。 コンピューティングの作成時に Azure portal または Studio から、または以下を使用して Azure CLI から、ID を有効にできます。 詳細については、コンピューティング クラスターでのマネージド ID の使用に関するページを参照してください。

適用対象: Azure CLI ML 拡張機能 v2 (現行)

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

マネージド ID には、トレーニング用の Docker イメージのプルを有効にするために、ワークスペース ACR の ACRPull ロールが自動的に付与されます。

注意

ワークスペース ACR を作成する前に、最初にコンピューティングを作成する場合は、ACRPull ロールを手動で割り当てる必要があります。

推論に Docker イメージを使用する

前述のように管理者ユーザーなしで ACR を構成した後は、Azure Kubernetes Service (AKS) から管理者キーを使用せずに、推論用の Docker イメージにアクセスできます。 AKS をワークスペースで作成、またはワークスペースにアタッチすると、クラスターのサービス プリンシパルに、ワークスペース ACR への ACRPull アクセスが自動的に割り当てられます。

注意

独自の AKS クラスターを使用する場合は、マネージド ID の代わりにサービス プリンシパルがクラスターで有効になっている必要があります。

シナリオ: プライベート Azure Container Registry を使用する

既定では、Azure Machine Learning では、Microsoft によって管理されるパブリック リポジトリから取得した Docker ベース イメージが使用されます。 次に、そのイメージ上にトレーニング環境または推論環境が構築されます。 詳細については、ML 環境とはに関するページを参照してください。

ACR 自社内のカスタム ベース イメージを使用するために、マネージド ID を使用してプライベート ACR にアクセスできます。 次の 2 つのユース ケースがあります。

  • トレーニングにベース イメージをそのまま使用します。
  • カスタム イメージをベースとして使用して、Azure Machine Learning マネージド イメージをビルドします。

機械学習コンピューティング クラスターに Docker ベース イメージをプルして、そのままトレーニングを行う

上記で説明したように、システム割り当てマネージド ID が有効になっている機械学習コンピューティング クラスターを作成します。 次に、マネージド ID のプリンシパル ID を決定します。

適用対象: Azure CLI ML 拡張機能 v2 (現行)

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

必要に応じて、コンピューティング クラスターを更新して、ユーザー割り当てマネージド ID を割り当てることができます。

適用対象: Azure CLI ML 拡張機能 v2 (現行)

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

コンピューティング クラスターでベース イメージをプルできるようにするには、マネージド サービス ID にプライベート ACR の ACRPull ロールを付与します。

適用対象: Azure CLI ML 拡張機能 v2 (現行)

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

最後に、環境を作成し、環境 YAML ファイル内の基本イメージの場所を指定します。

適用対象: Azure CLI ML 拡張機能 v2 (現行)

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

これで、トレーニング ジョブでその環境を使用できるようになりました。

トレーニングまたは推論用に、プライベート ACR からベース イメージに Azure Machine Learning マネージド環境をビルドする

適用対象: Azure CLI ML 拡張機能 v2 (現行)

このシナリオでは、Azure Machine Learning サービスによって、プライベート ACR から提供するベース イメージ上にトレーニングまたは推論環境がビルドされます。 イメージのビルド タスクは、ワークスペース ACR 上で ACR タスクを使用して実行されるため、アクセスを許可するためにその他の手順を実行する必要があります。

  1. ユーザー割り当てマネージド ID を作成し、ID にプライベート ACR への ACRPull アクセス権を付与します。

  2. ワークスペースのマネージド ID に、前の手順のユーザー割り当てマネージド IDマネージド ID オペレーター ロールを付与します。 このロールによってワークスペースでは、マネージド環境をビルドするために、ユーザー割り当てマネージド ID を ACR タスクに割り当てることができるようになります。

    1. ワークスペースのシステム割り当て マネージド ID のプリンシパル ID を取得します。

      適用対象: Azure CLI ML 拡張機能 v2 (現行)

      az ml workspace show -w <workspace name> -g <resource group> --query identityPrincipalId
      
    2. マネージド ID オペレーター ロールを付与します。

      az role assignment create --assignee <principal ID> --role managedidentityoperator --scope <user-assigned managed identity resource ID>
      

      ユーザー割り当てマネージド ID リソース ID は、ユーザー割り当て ID の Azure リソース ID で、/subscriptions/<subscription ID>/resourceGroups/<resource group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<user-assigned managed identity name> の形式です。

  3. az ml connection コマンド使用して、ワークスペース接続の外部 ACR とユーザー割り当てマネージド ID のクライアント ID を指定します。 このコマンドは、接続に関する情報を提供する YAML ファイルを受け入れます。 次の例では、マネージド ID を指定する形式を示します。 client_idresource_id の値を実際のマネージド ID の値に置き換えます。

    適用対象: Azure CLI ML 拡張機能 v2 (現行)

    name: test_ws_conn_cr_managed
    type: container_registry
    target: https://test-feed.com
    credentials:
      type: managed_identity
      client_id: client_id
      resource_id: resource_id
    

    次のコマンドは、YAML ファイルを使用してワークスペースとの接続を作成する方法を示しています。 <yaml file><workspace name>、並びに<resource group> を、構成の値に置き換えます:

    az ml connection create --file <yml file> --resource-group <resource group> --workspace-name <workspace>
    
  4. 構成が完了したら、トレーニングまたは推論用の環境のビルド時に、プライベート ACR のベース イメージを使用できるようになります。 次のコード スニペットは、環境定義内でベース イメージ ACR とイメージ名を指定する方法を示しています。

    適用対象: Python SDK azure-ai-ml v2 (現行)

    $schema: https://azuremlschemas.azureedge.net/latest/environment.schema.json
    name: private-acr-example
    image: <acr url>/pytorch/pytorch:latest
    description: Environment created from private ACR.
    

次のステップ