ワークロード ID フェデレーション

  • [アーティクル]

この記事では、ソフトウェア ワークロードのワークロード ID フェデレーションについて概説します。 ワークロード ID フェデレーションを使うと、シークレットを管理する必要なく、Microsoft Entra で保護されたリソースにアクセスできます (サポートされているシナリオの場合)。

ワークロード ID フェデレーションは、GitHub Actions、Kubernetes で実行されているワークロード、Azure の外部のコンピューティング プラットフォームで実行されているワークロードなどのシナリオで使用できます。

ワークロード ID フェデレーションを使用する理由

ワークロード ID フェデレーションを使用する理由については、こちらのビデオをご覧ください。

通常、ソフトウェア ワークロード (アプリケーション、サービス、スクリプト、コンテナーベースのアプリケーションなど) では、リソースの認証とアクセス、または他のサービスとの通信を行う際に ID が必要になります。 これらのワークロードを Azure で実行する場合は、 マネージド ID を使用できます。その場合、資格情報は Azure プラットフォームによって管理されます。 ただし、マネージド ID は、Azure で実行されているソフトウェア ワークロードにのみ使用できます。 Azure の外部で実行されるソフトウェア ワークロードの場合は、アプリケーション資格情報 (シークレットまたは証明書) を使用して、Microsoft Entra で保護されたリソース (Azure、Microsoft Graph、Microsoft 365、サード パーティのリソースなど) にアクセスする必要があります。 これらの資格情報はセキュリティ上のリスクをもたらすため、安全に保管し、定期的にローテーションする必要があります。 また、資格情報の有効期限が切れると、サービスのダウンタイムのリスクも発生します。

ワークロード ID フェデレーションを使用して、GitHub や Google などの外部 ID プロバイダー (IdP) からのトークンを信頼するように Microsoft Entra ID のユーザー割り当てマネージド ID またはアプリ登録を構成します。 Microsoft Entra ID のユーザー割り当てマネージド ID またはアプリの登録は、オンプレミスの Kubernetes や GitHub Actions ワークフローなどで実行されているソフトウェア ワークロードの ID になります。 その信頼関係が作成されると、外部のソフトウェア ワークロードは、外部 IdP からの信頼されたトークンを Microsoft ID プラットフォームからのアクセス トークンと交換します。 ソフトウェア ワークロードは、そのアクセス トークンを使用して、ワークロードにアクセス権が付与されている Microsoft Entra で保護されたリソースにアクセスします。 資格情報を手動で管理するメンテナンスの負担がなくなり、シークレットが漏洩するリスクや、証明書の有効期限が切れるリスクが排除されます。

サポートされるシナリオ

ワークロード ID フェデレーションを使用して Microsoft Entra で保護されたリソースにアクセスする場合、次のシナリオがサポートされます。

  • 任意の Kubernetes クラスター (Azure Kubernetes Service (AKS)、アマゾン ウェブ サービスの EKS、Google Kubernetes Engine (GKE)、またはオンプレミス) で実行されているワークロード。 Microsoft Entra ID のユーザー割り当てマネージド ID またはアプリと Kubernetes ワークロードとの間に信頼関係を確立します (ワークロード ID の概要に関するページを参照)。
  • Github Actions 最初に、Microsoft Entra 管理センターまたは Microsoft Graph を使用して、Microsoft Entra ID のユーザー割り当てマネージド ID またはアプリケーションと GitHub リポジトリとの間に信頼関係を構成します。 次に、Microsoft ID プロバイダーからアクセス トークンを取得して Azure リソースにアクセスするように GitHub Actions ワークフローを構成します。
  • Google Cloud。 まず、Microsoft Entra ID のユーザー割り当てマネージド ID またはアプリと Google Cloud の ID との間に信頼関係を構成します。 次に、Google Cloud で実行中のソフトウェア ワークロードを構成して、Microsoft ID プロバイダーからアクセス トークンを取得し、Microsoft Entra で保護されたリソースにアクセスできるようにします。 Google Cloud 内のアプリから Microsoft Entra で保護されたリソースにアクセスする方法に関する記事を参照してください。
  • アマゾン ウェブ サービス (AWS) で実行されているワークロード。 まず、Microsoft Entra ID のユーザー割り当てマネージド ID またはアプリと Amazon Cognito の ID との間に信頼関係を構成します。 次に、AWS で実行中のソフトウェア ワークロードを構成して、Microsoft ID プロバイダーからアクセス トークンを取得し、Microsoft Entra で保護されたリソースにアクセスできるようにします。 AWS でのワークロード ID フェデレーションに関するページをご覧ください。
  • Azure の外部のコンピューティング プラットフォームで実行されているその他のワークロード。 Microsoft Entra ID のユーザー割り当てマネージド ID またはアプリケーションとコンピューティング プラットフォームの外部 IdP との間に信頼関係を構成します。 そのプラットフォームによって発行されたトークンを使用して Microsoft ID プラットフォームで認証し、Microsoft エコシステム内で API を呼び出すことができます。 クライアント資格情報フローを使用して、Microsoft ID プラットフォームからアクセス トークンを取得し、保存された証明書を使用して自分で作成する代わりに、ID プロバイダーの JWT を渡します。
  • SPIFFE と SPIRE は、プラットフォームとクラウド ベンダーにデプロイされたソフトウェア ワークロードに ID を提供するためのプラットフォームに依存しないオープン ソース標準のセットです。 まず、Microsoft Entra ID のユーザー割り当てマネージド ID またはアプリと外部ワークロードの SPIFFE ID との間に信頼関係を構成します。 次に、外部ソフトウェア ワークロードを構成して、Microsoft ID プロバイダーからアクセス トークンを取得し、Microsoft Entra で保護されたリソースにアクセスできるようにします。 SPIFFE と SPIRE を使用したワークロード ID フェデレーションに関するページをご覧ください。
  • Azure Pipelines (プレビュー) に新しいサービス接続を作成します。 ワークロード ID フェデレーションを使用して、Azure Resource Manager サービス接続を作成します。

Note

Microsoft Entra ID で発行されたトークンは、フェデレーション ID フローには使用されない場合があります。 フェデレーション ID 資格情報フローでは、Microsoft Entra ID によって発行されたトークンはサポートされていません。

動作方法

外部 IdP と Microsoft Entra ID のユーザー割り当てマネージド ID またはアプリケーションとの間に信頼関係を作成します。 フェデレーション ID 資格情報は、外部 IdP からのどのトークンをアプリケーションかマネージド IDで信頼する必要があるかを示すために使用されます。 次のいずれかでフェデレーション ID を構成します。

  • Microsoft Entra 管理センター、Azure CLI、Azure PowerShell、Azure SDK、Azure Resource Manager (ARM) テンプレートを使用した、ユーザー割り当てマネージド ID 上で。 外部ワークロードは、シークレットを管理する必要なく、アクセス トークンを使用して、Microsoft Entra で保護されたリソースにアクセスします (サポートされているシナリオの場合)。 信頼関係を構成する手順 は、シナリオと外部 IdP によって異なります。
  • Microsoft Entra 管理センターでの、または Microsoft Graph を使用したアプリの登録で。 この構成により、Azure の外部でシークレットを管理しなくても、アプリケーションのアクセス トークンを取得できます。 詳細については、 外部 ID プロバイダーを信頼するようにアプリを構成する方法をご確認ください。

ただし、外部トークンをアクセス トークンに交換するワークフローは、すべてのシナリオで同じです。 次の図は、外部トークンをアクセス トークンと交換した後で Microsoft Entra で保護されたリソースにアクセスするワークロードの一般的なワークフローを示しています。

Diagram showing an external token exchanged for an access token and accessing Azure

  1. 外部ワークロード (GitHub Actions ワークフローなど) が、外部 IdP (GitHub など) のトークンを要求します。
  2. 外部 IdP が、外部ワークロードにトークンを発行します。
  3. 外部ワークロード (たとえば、GitHub ワークフローでのログイン アクション) が、トークンを Microsoft ID プラットフォームに送信し、アクセス トークンを要求します。
  4. Microsoft ID プラットフォームによって、ユーザー割り当てマネージド ID またはアプリ登録に対する信頼関係が確認され、外部 IdP の OpenID Connect (OIDC) 発行者 URL に対して外部トークンが検証されます。
  5. 確認が得られると、Microsoft ID プラットフォームが外部ワークロードにアクセス トークンを発行します。
  6. 外部ワークロードが、Microsoft ID プラットフォームのアクセス トークンを使用して、Microsoft Entra で保護されたリソースにアクセスします。 たとえば、GitHub Actions ワークフローが、アクセス トークンを使用して Web アプリを Azure App Service に発行します。

この Microsoft ID プラットフォームには、外部 IdP の OIDC エンドポイントからダウンロードされた最初の 100 個の署名キーのみが格納されます。 この外部 IdP によって 100 個を超える署名キーが公開される場合、ワークロード ID フェデレーションを使用すると、エラーが発生することがあります。

次の手順

ワークロード ID フェデレーションのしくみについて学習します。

  • ユーザー割り当てマネージド IDでフェデレーション ID 資格情報を作成、削除、取得、または更新する方法。
  • アプリ登録でフェデレーション ID 資格情報を作成、削除、取得、または更新する方法。
  • Microsoft ID プロバイダーからアクセス トークンを取得し、Microsoft Entra で保護されたリソースにアクセスするように Kubernetes ワークロードを構成する方法については、ワークロード ID の概要に関するページを参照してください。
  • GitHub Actions のドキュメントを読んで、Microsoft ID プロバイダーからアクセス トークンを取得して Microsoft Entra で保護されたリソースにアクセスするための GitHub Actions ワークフローを構成する方法の詳細を確認してください。
  • Microsoft Entra ID が OAuth 2.0 クライアント資格情報付与と別の IdP によって発行されたクライアント アサーションを使用してトークンを取得する方法。
  • 外部 ID プロバイダーによって作成される JWT の指定の形式については、「アサーションの形式」を参照してください。