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

ワークロード ID フェデレーションによって、シークレットを管理せずに Microsoft Entra で保護されたリソースに安全にアクセスできるようにする方法について説明します。 この記事では、その利点とサポートされるシナリオの概要について説明します。

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

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

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

通常、ソフトウェア ワークロード (アプリケーション、サービス、スクリプト、コンテナーベースのアプリケーションなど) では、リソースの認証とアクセス、または他のサービスとの通信を行う際に ID が必要になります。 これらのワークロードが Azure で実行されると、 マネージド ID を 使用でき、Azure プラットフォームによって資格情報が管理されます。 Azure の外部で実行されているソフトウェア ワークロード、または Azure で実行されているが、ID にアプリの登録を使用するソフトウェア ワークロードの場合は、アプリケーション資格情報 (シークレットまたは証明書) を使用して、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 ID の ユーザー割り当てマネージド ID または アプリケーション と、Microsoft Entra 管理センター の GitHub リポジトリ、または Microsoft Graph を使用して、信頼関係を構成します。 次に、Microsoft ID プロバイダーからアクセス トークンを取得し、Azure リソースにアクセスするように GitHub Actions ワークフローを構成 します。
• アプリ ID を使用して Azure コンピューティング プラットフォームで実行されているワークロード。 まず、ユーザー割り当てマネージド ID を Azure VM または App Service に割り当てます。 その後、アプリとユーザーに割り当てられた ID の間に信頼関係を構築します。
• 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 サービス接続を作成します。

注

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

動作方法

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

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

注

このシナリオが承認されるには、フェデレーション ID 資格情報 issuer、subject、audience の各値が、外部 IdP によって Microsoft Entra ID に送信されるトークンに指定された対応する issuer、subject、audience の各値と一致する (大文字と小文字は区別される) 必要があります。 この変更に関する詳細については、「 認証の新機能」を参照してください。

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

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 をフェデレーション ID 資格情報として設定します。
• ワークロード ID の概要を読み、Microsoft ID プロバイダーからアクセス トークンを取得し、Microsoft Entra で保護されたリソースにアクセスするように Kubernetes ワークロードを構成する方法について説明します。
• GitHub Actions のドキュメントを参照して、Microsoft ID プロバイダーからアクセス トークンを取得し、Microsoft Entra で保護されたリソースにアクセスするように GitHub Actions ワークフローを構成する方法の詳細を確認してください。
• Microsoft Entra ID が OAuth 2.0 クライアント資格情報付与 と、別の IdP によって発行されたクライアント アサーションを使用してトークンを取得する方法。
• 外部 ID プロバイダーによって作成される JWT の必要な形式については、 アサーション形式を参照してください。