GitHub Actionsを安全にAzure Machine Learningに接続する

検証ワークフローで、コード エラーが mainに到達する前にキャッチできるようになりました。 次の手順では、これらのワークフローをAzure Machine Learning (ジョブの送信、結果の読み取り、モデルの登録) と通信させることです。 これには認証が必要であり、セキュリティ上の問題を処理する方法が必要です。

シークレットと変数

GitHubには、ワークフロー構成を格納するための 2 つの場所が用意されています。

• シークレット は、資格情報やその他の機密性の高い構成の暗号化された値です。 GitHubは認識されたシークレット値をログにマスクしますが、ワークフローではそれらを公開しないようにする必要があります。
• 変数 は機密性のない構成情報を保持します。 ワークスペース名、リソース グループ名、ワークフロー間で再利用する類似の値に使用します。

環境スコープのシークレットは、リポジトリシークレットよりも適用範囲が限定されます。ジョブがそれらにアクセスするには、まずその環境を対象にする必要があります。

サービス プリンシパルと最小特権

Azureするワークフローを認証する方法の 1 つは、サービス プリンシパル (Microsoft Entra IDの人間以外の ID) を使用することです。 プリンシパルを作成し、Azure ロールを割り当て、その資格情報をGitHub シークレットとして格納します。

ロールとスコープは重要です。 Azure Machine Learning ワークスペースやそのリソース グループなど、ワークフローが必要とする最も狭いスコープで適切なロールを割り当てます。

OpenID Connect を使用したワークロード ID のフェデレーション

有効期間の長い資格情報をシークレットとして格納すると、リスクが生じます。シークレットが公開されている場合、ローテーションするまで有効なままです。 OpenID Connect (OIDC) とのワークロード ID フェデレーションでは、その有効期間が長い資格情報の格納を回避できます。

クライアント シークレットを格納する代わりに、GitHub リポジトリとMicrosoft Entra アプリケーションの間に信頼関係を構成します。 ワークフローを実行すると、GitHubは有効期間の短い OIDC トークンを発行します。 Azureはトークンを検証し、アクセス トークンを返します。保存された資格情報は交換されません。

ワークフロー認証と Git 追跡

ローカル Git リポジトリからソース ファイルを送信すると、Azure Machine Learningは、トレーニング ジョブを使用してリポジトリ、ブランチ、コミットを記録できます。 この追跡は、互換性のある Git サービスで動作し、ワークスペースに特定のGitHub リポジトリをアタッチしません。

Git 追跡とワークフロー認証によって、さまざまな問題が解決されます。 追跡は、ジョブをそのジョブを生成したソース バージョンに関連付けます。 認証により、そのジョブを送信するアクセス許可がワークフローに付与されます。