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 Machine Learning ワークスペース。 所有していない場合は、クイック スタート: ワークスペース リソースの作成に関する記事の手順に従って作成してください。
Azure CLI と
ml
拡張機能または Azure Machine Learning Python SDK v2:Azure CLI と拡張機能をインストールするには、「CLI (v2) のインストール、セットアップ、および使用」を参照してください。
重要
この記事の CLI の例では、Bash (または互換性のある) シェルを使用していることを前提としています。 たとえば、Linux システムや Linux 用 Windows サブシステムなどです。
Python SDK v2 をインストールするには、次のコマンドを使用します。
pip install azure-ai-ml azure-identity
SDK の既存のインストールを最新バージョンに更新するには、次のコマンドを使用します。
pip install --upgrade azure-ai-ml azure-identity
詳細については、「Azure Machine Learning 用 Python SDK v2 のインストール」を参照してください。
ロールを割り当てるには、Azure サブスクリプションのログインにマネージド ID オペレーター ロール、または必要なアクション (所有者など) を付与するその他のロールが含まれている必要があります。
マネージド ID の作成と操作に慣れている必要があります。
ワークスペース ID の種類
Azure Machine Learning ワークスペースでは、マネージド ID を使用して他のサービスと通信します。 Azure Machine Learning では、複数の ID の種類がサポートされています。
マネージド ID の種類 | ロールの割り当ての作成 | 目的 |
---|---|---|
システム割り当て (SAI) | マイクロソフト管理 | リソースに関連付けられているライフサイクル、単一リソースの使用、使用開始が簡単 |
システム割り当て + ユーザー割り当て (SAI+UAI) | ユーザーが管理 | ユーザー割り当て ID の独立したライフサイクル、複数リソースの使用、最低特権アクセスを制御。 トレーニング ジョブ内のデータにアクセス。 |
SAI ID タイプを使用してワークスペースを作成した後、それを SAI+UAI に更新することはできますが、SAI+UAI から SAI に戻すことはできません。 同じワークスペースに複数のユーザー割り当て ID を割り当てることができます。
Azure Container Registry と ID の種類
この表の一覧は、認証方法と Azure Container Registry の公衆ネットワーク アクセスの構成に応じた、Azure Container Registry に対する認証のサポート マトリックスです。
認証方法 | パブリック ネットワーク アクセス は無効 |
Azure Container Registry 公衆ネットワーク アクセスが有効 |
---|---|---|
管理者ユーザー | ✓ | ✓ |
ワークスペースのシステム割り当てマネージド ID | ✓ | ✓ |
ユーザー割り当てマネージド ID
ワークスペース
Azure portal から Azure Machine Learning ワークスペースを作成するときに、ユーザー割り当てマネージド ID を追加できます。 ワークスペースを作成する際は、次の手順に従います。
- [基本] ページで、ワークスペースで使用する Azure Storage アカウント、Azure Container Registry、Azure Key Vault を選びます。
- [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 に加えて、ユーザー割り当てマネージド ID をワークスペースに追加する
一部のシナリオでは、既定のシステム割り当てワークスペース ID に加えて、ユーザー割り当てマネージド ID を使うことが必要になる場合があります。 既存のワークスペース ID を変更せずにユーザー割り当てマネージド ID を追加するには、次の手順のようにします。
「ユーザー割り当てマネージド ID を作成する」の手順を使用して、ユーザー割り当てマネージド ID を作成します。 作成するマネージド ID の ID を保存します。
マネージド ID をワークスペースにアタッチするには、ID を指定する YAML ファイルが必要です。 次に示すのは YAML ファイルの内容の例です。
<TENANT_ID>
、<RESOURCE_GROUP>
、<USER_MANAGED_ID>
は、実際の値に置き換えます。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>': {}
Azure CLI の
az ml workspace update
コマンドを使って、ワークスペースを更新します。--file
パラメーターを使って、前のステップの YAML ファイルを指定します。 このコマンドは、次の例のようになります。az ml workspace update --resource-group <RESOURCE_GROUP> --name <WORKSPACE_NAME> --file <YAML_FILE_NAME>.yaml
コンピューティング クラスター
Note
Azure Machine Learning コンピューティング クラスターは、システムによって割り当てられた 1 つの ID またはユーザーによって割り当てられた複数の ID のみをサポートします。両方同時にはサポートしません。
既定のマネージド ID は、システムによって割り当てられたマネージド ID、またはユーザーが割り当てた最初のマネージドID です。
実行中、ID は次の 2 つの方法で利用されます。
ユーザーのストレージ マウント、コンテナー レジストリ、データストアを設定するために、システムによって ID が使用されます。
- この場合、システムは既定のマネージド ID を使用します。
送信されたジョブのコード内からリソースにアクセスするために 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 に基づくデータ アクセスを設定する方法について説明します。
ストレージ リソースへのアクセス権をユーザー ID に付与します。 たとえば、使用する特定のストレージ アカウントに StorageBlobReader アクセス権を付与するか、Azure Data Lake Gen 2 ストレージ内の特定のフォルダーまたはファイルに ACL ベースのアクセス許可を付与します。
ストレージ アカウントの資格情報をキャッシュせずに、Azure Machine Learning データストアを作成します。 データストアにストレージ アカウント キーなどの資格情報がキャッシュされる場合、それらの資格情報がユーザー ID の代わりに使用されます。
次のジョブの仕様に示すように、プロパティ identity が type: 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 に基づくデータ アクセスを設定する方法について説明します。
CLI について前述したように、データ アクセスを許可し、データ ストアを作成します。
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
新しい Azure Machine Learning ワークスペースを作成します。
Azure Container Registry を必要とするアクションを実行します。 「チュートリアル: 最初のモデルをトレーニングする」はその例です。
クラスターによって作成された ACR の名前を取得します。
適用対象: Azure CLI ml 拡張機能 v2 (現行)
az ml workspace show --name <my workspace name> \ --resource-group <my resource group> \ --subscription <my subscription id> \ --query container_registry
このコマンドにより、次のテキストのような値が返されます。 テキストの最後の部分 (ACR インスタンス名) のみが必要です。
/subscriptions/<subscription id>/resourceGroups/<my resource group>/providers/MicrosoftContainerReggistry/registries/<ACR instance name>
ACR を更新して、管理者ユーザーを無効にします。
az acr update --name <ACR instance name> --admin-enabled false
独自の ACR を使用する
ACR 管理者ユーザーがサブスクリプション ポリシーによって禁止されている場合は、まず管理者ユーザーなしで ACR を作成し、それをワークスペースに関連付けます。
--admin-enabled
引数を設定せずに Azure CLI から ACR を作成するか、管理者ユーザーを有効にせずに Azure portal から ACR を作成します。 次に、Azure Machine Learning ワークスペースを作成するときに、ACR の Azure リソース ID を指定します。 次の例は、既存の ACR を使用する新しい Azure Machine Learning ワークスペースを作成する方法を示しています。
適用対象: Azure CLI ml 拡張機能 v2 (現行)
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>
ヒント
--container-registry
パラメーターの値を取得するには、az acr show コマンドを使用して ACR の情報を表示します。 id
フィールドに、ACR のリソース ID が表示されます。
また、管理者ユーザーが無効になっている既存の ACR がある場合は、それを更新してワークスペースにアタッチすることもできます。 次に示すのは、既存の ACR を使うように Azure Machine Learning ワークスペースを更新する方法の例です。
適用対象: Azure CLI ml 拡張機能 v2 (現行)
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>
マネージド 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> -n <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 マネージド環境をビルドする
Note
ユーザー割り当てマネージド ID を使用したプライベート ACR への接続は、現在サポートされていません。 管理者キーは、プライベート ACR でサポートされている唯一の認証の種類です。
次のステップ
- Azure Machine Learning のエンタープライズ セキュリティの詳細情報
- データ管理について
- コンピューティング クラスターでのマネージド ID について確認する。