概要
OpenID Connect (OIDC) を使用すると、GitHub Actions ワークフローでは、有効期間の長い GitHub シークレットとして Azure 資格情報を格納しなくても、Azure 内のリソースにアクセスできます。
このガイドでは、GitHub の OIDC をフェデレーション ID として信頼するように Azure を構成する方法の概要と、トークンを使用して Azure に対する認証とリソースへのアクセスを行う azure/login アクションのワークフロー例を示します。
前提条件
-
GitHub が OpenID Connect (OIDC) を使用する方法の基本的な概念とそのアーキテクチャと利点については、「OpenID Connect を使ったセキュリティ強化について」を参照してください。
-
先に進む前に、アクセス トークンが予測可能な方法でのみ割り当てられるようにセキュリティ戦略を計画する必要があります。 クラウド プロバイダーがアクセス トークンを発行する方法を制御するには、少なくとも 1 つの条件を定義し、信頼できないリポジトリがクラウド リソースにアクセス トークンを要求できないようにする必要があります。 詳しくは、「OpenID Connect を使ったセキュリティ強化について」を参照してください。
フェデレーション認証情報を Azure に追加する
GitHubの OIDC プロバイダーは、Azure のワークロード ID フェデレーションと連携します。 概要については、「ワークロード ID フェデレーション」の Microsoft のドキュメントを参照してください。
Azure で OIDC ID プロバイダーを構成するには、次の構成を実行する必要があります。 これらの変更を行う手順については、Azure のドキュメントを参照してください。
次の手順では、Microsoft Entra ID (旧称 Azure AD) 用のアプリケーションを作成します。
- Entra ID アプリケーションとサービス プリンシパルを作成します。
- Entra ID アプリケーションのフェデレーション認証情報を追加します。
- Azure 構成を格納するための GitHub シークレットを作成します。
ID プロバイダーを構成するための追加のガイダンス:
- セキュリティ強化については、必ず「OpenID Connect を使ったセキュリティ強化について」をご確認ください。 例については、「OpenID Connect を使ったセキュリティ強化について」をご覧ください。
- この
audience設定では、推奨される値はapi://AzureADTokenExchangeですが、ここで他の値を指定することもできます。
GitHub Actions ワークフローを更新する
OIDC のワークフローを更新するには、YAML に 2 つの変更を行う必要があります。
- トークンのアクセス許可設定を追加します。
- この
azure/loginアクションを使って、OIDC トークン (JWT) をクラウド アクセス トークンと交換します。
独自のカスタム保護規則を有効にして、サードパーティ サービスを使ったデプロイを制御できます。 たとえば、Datadog、Honeycomb、ServiceNow などのサービスを使用し、GitHub への展開に対して自動承認を提供できます。
アクセス許可設定の追加
ジョブまたはワークフローの実行には、GitHub の OIDC プロバイダーが実行ごとに JSON Web Token を作成できるようにするために、id-token: write を含む permissions 設定が必要です。 id-token の permissions が write に設定されていない場合、OIDC JWT ID トークンを要求することはできません。ただし、この値はリソースへの書き込みアクセスを許可することを意味せず、アクションまたはステップの OIDC トークンをフェッチして設定し、有効期間の短いアクセス トークンを使用して認証を有効にできるだけです。 実際の信頼の設定は OIDC 要求を使用して定義されます。詳細については、「OpenID Connect を使ったセキュリティ強化について」を参照してください。
この id-token: write 設定により、次のいずれかの方法を使用して、GitHub の OIDC プロバイダーから JWT を要求できます。
- ランナーで環境変数を使用する (
ACTIONS_ID_TOKEN_REQUEST_URLおよびACTIONS_ID_TOKEN_REQUEST_TOKEN)。 - アクション ツールキットから
getIDToken()を使用する。
ワークフローの OIDC トークンをフェッチする必要がある場合は、ワークフロー レベルでアクセス許可を設定できます。 次に例を示します。
permissions: id-token: write # This is required for requesting the JWT contents: read # This is required for actions/checkout
permissions:
id-token: write # This is required for requesting the JWT
contents: read # This is required for actions/checkout
1 つのジョブに対して OIDC トークンのみをフェッチする必要がある場合は、そのジョブ内でこのアクセス許可を設定できます。 次に例を示します。
permissions: id-token: write # This is required for requesting the JWT
permissions:
id-token: write # This is required for requesting the JWT
ワークフローの要件に応じて、ここで追加のアクセス許可を指定する必要がある場合があります。
呼び出し元ワークフローと同じユーザー、Organization、または Enterprise が所有する再利用可能なワークフローの場合、再利用可能なワークフローで生成された OIDC トークンに呼び出し元のコンテキストからアクセスできます。
Enterprise または Organization 外部の再利用可能なワークフローについては、id-token の permissions 設定を、呼び出し元ワークフロー レベル、または再利用可能ワークフローを呼び出す特定のジョブで write に設定してください。
これにより、再利用可能なワークフローで生成された OIDC トークンは、意図した場合にのみ呼び出し元ワークフローで使用できるようになります。
詳しくは、「ワークフローの再利用」を参照してください。
アクセス トークンの要求
この azure/login アクションでは、GitHub OIDC プロバイダーから JWT を受け取り、Azure からアクセス トークンを要求します。 詳細については、azure/login のドキュメントを参照してください。
次の例では、OIDC ID トークンを Azure と交換してアクセス トークンを受け取ります。これを使用すると、クラウド リソースにアクセスできます。
name: Run Azure Login with OIDC
on: [push]
permissions:
id-token: write
contents: read
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- name: 'Az CLI login'
uses: azure/login@a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- name: 'Run az commands'
run: |
az account show
az group list
name: Run Azure Login with OIDC
on: [push]
permissions:
id-token: write
contents: read
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- name: 'Az CLI login'
uses: azure/login@a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- name: 'Run az commands'
run: |
az account show
az group list