GitHub Actions ワークフローのワークロード ID を作成する
ワークロード ID の概念を理解したので、それを作成して GitHub Actions デプロイ ワークフローにリンクする方法を知りたいと思うかもしれません。 このユニットでは、それを実行する手順を示します。
Microsoft Entra アプリケーションを作成する
前のユニットで、ワークロード ID には Microsoft Entra ID での "アプリケーションの登録" の作成が必要なことを学習しました。
Note
アプリケーションの登録を作成および変更するには、Microsoft Entra ID でのアクセス許可が必要です。 組織によっては、管理者にこれらの手順を実行してもらう必要があります。
アプリケーションの登録を作成する際に、表示名を指定する必要があります。 表示名は、アプリケーションの登録について説明する、人間が判読できる名前です。
ヒント
アプリケーションの登録には、明確でわかりやすい表示名を使用してください。 誰かがアプリケーションの登録を誤って削除したり、そのアクセス許可を変更したりしないようにするために、その用途をチームが理解できるようにすることが重要です。
新しい Microsoft Entra アプリケーションを作成する Azure CLI コマンドの例を次に示します。
az ad app create --display-name $applicationRegistrationName
新しい Microsoft Entra アプリケーションを作成する Azure PowerShell コマンドの例を次に示します。
New-AzADApplication -DisplayName $applicationRegistrationName
上記のコマンドの出力には、次のような重要な情報が含まれています。
- アプリケーション ID: アプリケーション登録には、一意の識別子があります。多くの場合、これは "アプリケーション ID" (場合によっては "クライアント ID") と呼ばれます。 この識別子は、ワークフローで Azure にサインインする必要がある場合に使用します。
- オブジェクト ID:アプリケーションの登録には、Microsoft Entra ID によって割り当てられた一意識別子であるオブジェクト ID が含まれています。 このモジュールの後半で、オブジェクト ID を使用する方法の例を示します。
アプリケーションの登録を作成する際、通常は表示名のみを設定します。 Azure により、他の名前と識別子が自動的に割り当てられます。
注意事項
表示名は一意ではありません。 複数のアプリケーションの登録で、同じ表示名が共有される場合があります。 表示名を使用してアプリケーションの登録を識別して、それにアクセス許可を付与する場合には、注意が必要です。 間違ったアプリケーションの登録に、誤ってアクセス許可を付与してしまうおそれがあります。 代わりに、一意識別子のいずれかを使用することをお勧めします。
フェデレーション資格情報
ID は、Azure と通信する必要がある場合、Microsoft Entra ID にサインインします。 アプリケーションの登録だけでは、ワークフローまたはアプリケーションで Azure にサインインできません。 最初にいくつかの資格情報を割り当てる必要があります。 "フェデレーション資格情報" は、アプリケーション資格情報の一種です。 ほとんどの資格情報とは異なり、フェデレーション資格情報では、パスワードやキーなどのシークレットを管理する必要はありません。
デプロイ ワークフローのフェデレーション資格情報を作成するときに、Microsoft Entra ID と GitHub にお互いを信頼するよう、実質的に指示します。 この信頼は "フェデレーション" と呼ばれます。
その後、ワークフローでサインインを試みると、Microsoft Entra ID がサインインの試行を許可するかどうかを決定できるように GitHub によりワークフローの実行に関する情報が提供されます。 サインイン試行のたびに GitHub により Microsoft Entra ID に提供される情報には、次のフィールドを含めることができます。
- GitHub ユーザーまたは組織名。
- GitHub リポジトリ名。
- ワークフローが現在実行されているリポジトリのブランチ。
- ワークフロー ジョブでターゲットとする環境。 環境の詳細については、今後のモジュールで学習します。
- pull request の作成によってワークフローがトリガーされたかどうか。
上記のプロパティの値に応じて、GitHub からのサインイン試行を許可または拒否するように Microsoft Entra ID を構成できます。 たとえば、次のポリシーを適用できます。
- "組織内の特定の GitHub リポジトリからワークフローが実行される場合にのみ、サインインの試行を許可する。"
- 組織内の特定の GitHub リポジトリからワークフローが実行され、そのブランチ名が main である場合にのみ、サインインの試行を許可する。
デプロイ ワークフローでワークロード ID とフェデレーション資格情報を使用してサインインする方法の図を次に示します。
サインイン プロセスに関連する手順は次のとおりです。
ワークフローで Azure と通信する必要がある場合、GitHub は Microsoft Entra ID に安全に連絡して "アクセス トークン" を要求します。 GitHub は、GitHub 組織 (
my-github-user)、リポジトリ (my-repo)、ワークフローが実行されているブランチ (main) に関する情報を提供します。 また、これには Microsoft Entra ID 内のテナント ID、ワークフロー ID のアプリケーションの登録のアプリケーション ID、ワークフローによるデプロイの対象としたい Azure サブスクリプション ID も含まれます。Microsoft Entra ID によりアプリケーション ID が検証され、GitHub organization、リポジトリ、ブランチのアプリケーション内にフェデレーション資格情報が存在するかどうかが確認されます。
Microsoft Entra ID では、要求が有効であると判断されると、アクセス トークンが発行されます。 ワークフローでは、Azure Resource Manager と通信するときにそのアクセス トークンを使用します。
フェデレーション資格情報を作成する
Azure CLI を使用する場合は、JSON ファイルまたは変数を作成して、フェデレーション資格情報を定義します。 たとえば、次の JSON ファイルを見てください。
{
"name": "MyFederatedCredential",
"issuer": "https://token.actions.githubusercontent.com",
"subject": "repo:my-github-user/my-repo:ref:refs/heads/main",
"audiences": [
"api://AzureADTokenExchange"
]
}
そのファイルの subject プロパティでは、次の状況でワークフローが実行される場合にのみフェデレーション資格情報が有効であることを指定しています。
| フィールド | 値 |
|---|---|
| GitHub 組織名 | my-github-user |
| GitHub リポジトリ名 | my-repo |
| ブランチ名 | main |
JSON でポリシーを作成し、policy.json という名前のファイルに保存したら、Azure CLI を使用してフェデレーション資格情報を作成できます。
az ad app federated-credential create \
--id $applicationRegistrationObjectId \
--parameters @policy.json
Azure PowerShell を使用する場合は、次のような文字列を作成して、フェデレーション資格情報を定義します。
$policy = "repo:my-github-user/my-repo:ref:refs/heads/main"
上記の文字列では、次の状況でワークフローが実行される場合にのみ、フェデレーション資格情報が有効であることを指定しています。
| フィールド | 値 |
|---|---|
| GitHub 組織名 | my-github-user |
| GitHub リポジトリ名 | my-repo |
| ブランチ名 | main |
ポリシー文字列を作成したら、Azure PowerShell を使用してフェデレーション資格情報を作成できます。
New-AzADAppFederatedCredential `
-Name 'MyFederatedCredential' `
-ApplicationObjectId $applicationRegistrationObjectId `
-Issuer 'https://token.actions.githubusercontent.com' `
-Audience 'api://AzureADTokenExchange' `
-Subject $policy
ワークロード ID のライフサイクルを管理する
作成する各ワークロード ID のライフサイクル全体を考慮することが重要です。 デプロイ ワークフローのワークロード ID を作成する場合、ワークフローが最終的に削除されたり、使用されなくなったときには、どのようなことが起こるでしょうか。
ワークロード ID とフェデレーション資格情報は自動的に削除されないため、古いものを監査して削除する必要があります。 デプロイ ワークフローのワークロード ID は、再利用できるシークレット資格情報を含みませんが、それでも不要になったら削除することをお勧めします。 そうすれば、誰かが同じ名前で別の GitHub リポジトリを作成し、予期せず Azure 環境にアクセスできる可能性はなくなります。
自分とチームが簡単にアクセスできる場所で、ワークロード ID を文書化することをお勧めします。 各ワークロード ID には、次の情報を含めます。
- 名前やアプリケーション ID など、主要な識別情報
- その目的
- 作成者、管理担当者、問題発生時に回答できる可能性のある担当者
- それが必要とするアクセス許可と、それらを必要とする明確な理由
- 想定される有効期間
ワークロード ID を定期的に監査して、それらがまだ使用中であることと、割り当てられたアクセス許可が依然として正しいことを確認する必要があります。