Skip to main content

このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となります: 2026-03-17. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise サーバーにアップグレードしてください。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください

アマゾン ウェブ サービスでの OpenID Connect の構成

ワークフロー内で OpenID Connect を使用して、アマゾン ウェブ サービスで認証を行います。

メモ

GitHub ホステッド ランナーは、現在 GitHub Enterprise Server ではサポートされていません。

概要

OpenID Connect (OIDC) を使うと、GitHub Actions ワークフローでは、有効期間の長い GitHub シークレットとしてアマゾン ウェブ サービス (AWS) 資格情報を格納しなくても、AWS 内のリソースにアクセスできます。

このガイドでは、GitHub の OIDC をフェデレーション ID として信頼するように AWS を構成する方法と、トークンを使って AWS に対する認証とリソースへのアクセスを行う aws-actions/configure-aws-credentials のワークフロー例を示します。

メモ

OIDC のカスタム要求のサポートは、AWS では使用できません。

前提条件

  • GitHub が OpenID Connect (OIDC) を使用する方法の基本的な概念とそのアーキテクチャと利点については、「OpenID Connect」を参照してください。

  • 先に進む前に、アクセス トークンが予測可能な方法でのみ割り当てられるようにセキュリティ戦略を計画する必要があります。 クラウド プロバイダーがアクセス トークンを発行する方法を制御するには、少なくとも 1 つの条件を定義し、信頼できないリポジトリがクラウド リソースにアクセス トークンを要求できないようにする必要があります。 詳しくは、「OpenID Connect」をご覧ください。

  • クラウド プロバイダーが次の OIDC エンドポイントにアクセスできることを確認する必要があります。

    • http://HOSTNAME/_services/token/.well-known/openid-configuration
    • http://HOSTNAME/_services/token/.well-known/jwks

    メモ

    AWS IP アドレス範囲のみを許可することで、OIDC エンドポイントへのアクセスを制限できます。

    メモ

    GitHub では、AWS セッション タグがネイティブでサポートされていません。

AWS への ID プロバイダーの追加

GitHub OIDC プロバイダーを IAM に追加するには、AWS のドキュメントを参照してください。

  • プロバイダURLには http://HOSTNAME/_services/token を指定します
  • 「対象者」には sts.amazonaws.com を指定します。(公式のアクションを利用する場合)。

ロールと信頼ポリシーの構成

IAM でロールと信頼を構成するには、AWS ドキュメント「GitHub Actions 用の AWS 資格情報を構成する」と「Configuring a role for GitHub OIDC identity provider」(GitHub OIDC ID プロバイダーのロールを構成する) を参照してください。

メモ

AWS の ID とアクセス管理 (IAM) では、GitHub の OIDC ID プロバイダー (IdP) を信頼するすべてのロールの信頼ポリシーで、IAM 条件キー token.actions.githubusercontent.com:sub を評価することをお勧めします。 ロール信頼ポリシーでこの条件キーを評価すると、GitHub アクションがロールを引き受けられる制限があります。

信頼ポリシーを編集して、sub フィールドを検証条件に追加します。 次に例を示します。

JSON
"Condition": {
  "StringEquals": {
    "HOSTNAME/_services/token:aud": "sts.amazonaws.com",
    "HOSTNAME/_services/token:sub": "repo:octo-org/octo-repo:ref:refs/heads/octo-branch"
  }
}

環境でワークフローを使用する場合、sub フィールドは環境名 repo:ORG-NAME/REPO-NAME:environment:ENVIRONMENT-NAME を参照する必要があります。 詳しくは、「OpenID Connect リファレンス」をご覧ください。

独自のカスタム保護規則を有効にして、サードパーティ サービスを使ったデプロイを制御できます。 たとえば、Datadog、Honeycomb、ServiceNow などのサービスを使用し、GitHub への展開に対して自動承認を提供できます。

JSON
"Condition": {
  "StringEquals": {
    "HOSTNAME/_services/token:aud": "sts.amazonaws.com",
    "HOSTNAME/_services/token:sub": "repo:octo-org/octo-repo:environment:prod"
  }
}

次の例では、StringLike をワイルドカード演算子 (*) と共に使用して、任意のブランチ、pull request マージ ブランチ、または octo-org/octo-repo organization とリポジトリの環境が AWS でロールを引き受けることを許可します。

JSON
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::123456123456:oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringLike": {
                    "token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:*"
                },
                "StringEquals": {
                    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
                }
            }
        }
    ]
}

GitHub Actions ワークフローを更新する

OIDC のワークフローを更新するには、YAML に 2 つの変更を行う必要があります。

  1. トークンのアクセス許可設定を追加します。
  2. この aws-actions/configure-aws-credentials アクションを使って、OIDC トークン (JWT) をクラウド アクセス トークンと交換します。

アクセス許可設定の追加

GitHub の OIDC プロバイダーが実行ごとに JSON Web Token を作成できるよう、ジョブまたはワークフローの実行には id-token: write を含む permissions の設定が必要です。

メモ

ワークフローのアクセス許可で id-token: write を設定しても、リソースへの変更または書き込みを行うアクセス許可はワークフローに付与されません。 そうではなく、ワークフローは、アクションまたはステップのための OIDC トークンを要求 (フェッチ) して使用 (設定) することのみが許可されます。 その後、このトークンは、有効期間の短いアクセス トークンを使って外部サービスで認証を行うために使われます。

必要なアクセス許可、構成例、高度なシナリオについて詳しくは、「OpenID Connect リファレンス」をご覧ください。

アクセス トークンの要求

この aws-actions/configure-aws-credentials アクションを使うと、GitHub OIDC プロバイダーから JWT を受け取り、アクセス トークンを AWS に要求します。 詳細については、AWS のドキュメントを参照してください。

  • BUCKET-NAME: これを S3 バケットの名前に置き換えます。
  • AWS-REGION:ここれを、お客様のAWSリージョンの名前に置き換えてください。
  • ROLE-TO-ASSUME: AWS ロールに置き換えます。 たとえば、arn:aws:iam::1234567890:role/example-role のように指定します。
YAML
# Sample workflow to access AWS resources when workflow is tied to branch
# The workflow Creates static website using aws s3
name: AWS example workflow
on:
  push
env:
  BUCKET_NAME : "BUCKET-NAME"
  AWS_REGION : "AWS-REGION"
# permission can be added at job level or workflow level
permissions:
  id-token: write   # This is required for requesting the JWT
  contents: read    # This is required for actions/checkout
jobs:
  S3PackageUpload:
    runs-on: ubuntu-latest
    steps:
      - name: Git clone the repository
        uses: actions/checkout@v5
      - name: configure aws credentials
        uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502
        with:
          role-to-assume: ROLE-TO-ASSUME
          role-session-name: samplerolesession
          aws-region: ${{ env.AWS_REGION }}
      # Upload a file to AWS s3
      - name: Copy index.html to s3
        run: |
          aws s3 cp ./index.html s3://${{ env.BUCKET_NAME }}/

参考資料