ワークロード ID を理解する

  • 7 分

デプロイ ワークフロー、アプリケーション、ソフトウェアには、特別な認証方法が必要です。 このユニットでは、ワークロード ID がデプロイ ワークフローで重要である理由、それらが Azure のセキュリティ モデルにどのように適合するか、それらがどのように動作するかについて説明します。

ワークフローを認証する必要がある理由

Bicep ファイルをデプロイする場合、Azure リソースを作成または変更するように Azure Resource Manager に適切に指示します。 この例のシナリオでは、玩具会社の Web サイトをデプロイするために Bicep ファイルを作成しました。 Bicep ファイルにより、Azure App Service プラン、アプリ、Application Insights インスタンスを含むリソースが宣言されます。

ファイルをデプロイすると、Resource Manager により、リソースが存在するかどうかがチェックされます。 存在しない場合は、Resource Manager によって作成されます。 リソースが既に存在する場合、その構成が Bicep ファイルで指定した構成と一致していることが Resource Manager によって確認されます。

これらの操作はすべて、Azure リソースにアクセスして変更するため、アクセス許可が必要です。 デプロイに必要な特定のアクセス許可は、Bicep ファイルに含まれるものによって異なります。 玩具会社の Web サイトのサンプル ファイルをデプロイするには、デプロイ先のリソース グループ内で次のアクセス許可が必要になります。

  • デプロイを作成する権限。 デプロイは、Microsoft.Resources/deployments の種類のリソースです。
  • App Service プランとアプリを作成および変更する権限。
  • Application Insights インスタンスを作成および変更する権限。

これまでは、多くの場合、Azure CLI または Azure PowerShell を使用して自分で Bicep ファイルをデプロイしていました。 これらのツールを使用する場合、通常は自分のユーザー アカウントを使用し、ブラウザーを使用して認証を行います。 これは、自分の ID を使用して呼び出されます。 デプロイを送信すると、Bicep テンプレートで指定した内容を実行するのに必要なアクセス許可が ID にあるかどうかが Azure によって検証されます。

GitHub Actions デプロイ ワークフローに移行した後、デプロイはワークフローによって実行され、ユーザーは直接関与しないため、別の種類の ID を使う必要があります。

ID の種類

Microsoft Entra ID は、Azure の ID を管理するサービスです。 ID の主な種類は次のとおりです。

  • ユーザー ID: ユーザーは、通常ブラウザーを使って対話形式でサインインする人間を表します。 ユーザーには、多くの場合、サインイン時に実行する追加のセキュリティ チェックがあります。多要素認証 (MFA) や、場所やネットワークに基づく条件付きアクセスなどです。
  • グループ: グループは、ユーザーの集合を表します。 グループは、直接認証を行うのではなく、一連のユーザーにアクセス許可をまとめて割り当てる便利な方法です。
  • ワークロード ID: ワークロードは、通常は人間が直接実行しない、自動化されたプロセスまたはシステムを表します。 ワークロードは Microsoft Entra ID にサインインできますが、サインインして認証プロセスを操作する人間はいません。 ワークロード ID では、MFA や同様の保護は使用されません。それらの機能では、人が自分の身元を証明するために何かを行う必要があるためです。

このモジュールでは、ワークロード ID に重点を置きます。

マネージド ID

マネージド ID が Azure リソースに関連付けられます。 Azure は資格情報を自動的に管理します。 リソースが何かにアクセスする必要がある場合、Azure は資格情報を使用して自動的にサインインします。

マネージド ID は、仮想マシンや App Service アプリなど、Azure でホストされるリソースに対して使用できます。 これらは、Azure 管理の自動化、データベースへの接続、Azure Key Vault からの秘密データの読み取りなどの状況で、Azure リソースが自身を認証するための優れた方法です。 他のシナリオでも、Azure Arc でマネージド ID を使用することができます。

デプロイ ワークフローを使用する場合は通常、マネージド ID は使用しません。 マネージド ID では、デプロイを実行する Azure リソースを所有および管理する必要があります。 GitHub Actions を使用する場合は通常、Microsoft または GitHub によって提供される共有インフラストラクチャに依存します。 ただし、GitHub Actions でワークロード ID を使用する場合は、マネージド ID の主な利点が得られます。つまり、資格情報を管理する必要はありません。

ヒント

ソリューションのその他の部分で、マネージド ID を使うか、通常のサービス プリンシパルを使うかを選べる場合は、マネージド ID を使うのが最善です。 マネージド ID の方が使用しやすく、通常はより安全です。

自分のユーザー アカウントを使用できない理由

完全に機能するユーザー アカウントがあるのに、デプロイ ワークフローを認証するためだけに、このまったく新しい種類のオブジェクトを作成する必要があることを、疑問に思うかもしれません。

ユーザー アカウントは、無人使用のために設計されていません。 ユーザー アカウントの認証プロセスでは、多くの場合、サインインしようとしているのが人間であるかがチェックされます。 組織が認証時に追加のセキュリティ チェックを使用することが増えています。 これらのチェックには、サインイン要求の正当性を検証できるよう、MFA、CAPTCHA チェック、ユーザーが使っているデバイスとネットワークの検査などが含まれます。

ワークフローは、誰もアクティブに実行していない場合でもデプロイを実行できるように設計されています。 実際に、デプロイ ワークフローのほとんどの利点は、それが自動化されていて人間の介入を必要としないという事実に由来します。

ユーザー名とパスワードをワークフローに保存し、それらを使用してサインインしようとしても、機能しないはずです。 これらが機能しているように見える場合でも、将来、Microsoft Entra ID または組織の管理者がユーザー認証プロセスにセキュリティ チェックをさらに追加すると、簡単に機能しなくなる可能性があります。

警告

また、ユーザー名とパスワードを任意の場所に保存するのは、他のユーザーがアクセスし、それらを使用してなりすましを行う可能性があるため、適切ではありません。

このような理由から、Azure とやり取りする組み込みの GitHub Actions タスクでは、ユーザー アカウントの資格情報を指定できません。 ワークロード ID を使用する必要があります。

ワークロード ID のしくみ

ワークロード ID は、グローバル ID サービスである Microsoft Entra ID の機能です。 多くの会社が Microsoft Entra ID を使用しており、各会社は "テナント" と呼ばれます。

Microsoft Entra ID には "アプリケーション" という概念があり、システム、ソフトウェア、プロセス、または人間ではないその他のエージェントを表します。 デプロイ ワークフローもアプリケーションと考えることができます。

アプリケーションを作成し、それについて Microsoft Entra ID に知らせる場合、"アプリケーションの登録" と呼ばれるオブジェクトを作成します。 アプリケーションの登録は、Microsoft Entra ID でのアプリケーションを表します。

アプリケーション登録には、"フェデレーション資格情報" を関連付けることができます。 フェデレーション資格情報では、シークレットを格納する必要はありません。 代わりに、それらによって、GitHub などのサポートされているサービスによる Microsoft Entra アプリケーションの使用が有効にされます。

GitHub Actions ワークフローは、認証を行う必要があると、GitHub を介して Microsoft Entra ID に接続します。 GitHub は、GitHub の組織とリポジトリの名前、および必要に応じて他の情報を Microsoft Entra ID に伝えます。 リポジトリの詳細と一致するフェデレーション資格情報を構成してある場合、Microsoft Entra によってデプロイ ワークフローが認証されます。 ワークフローでは、アプリケーションに割り当てたアクセス許可を使用できます。

ヒント

Azure portal でアプリケーションの登録を確認すると、関連性がないように見える他の機能と構成が数多く表示されます。 これは、認証とワークフローのデプロイの範囲を超える多くのことを、アプリケーションは Microsoft Entra ID で実行できるためです。

Microsoft Entra テナントで "サービス プリンシパル" オブジェクトを作成することもできます。 サービス プリンシパルは、独自の Microsoft Entra テナントが使用するアプリケーションのコピーのようなものです。 サービス プリンシパルとアプリケーションは緊密にリンクされます。 このモジュールの後半で、Azure にアクセスするためのアクセス許可をワークフローに付与するときに、サービス プリンシパルを使用します。

注意

一部のツールでは、サービス プリンシパルを ''エンタープライズ アプリケーション'' と呼びます。 "ローカル ディレクトリ内のマネージド アプリケーション" というサービス プリンシパルが表示される場合もありますが、これらはマネージド ID と同じものではありません。