0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【GitHub Actions】AssumeRoleWithWebIdentity に失敗した原因は sub の仕様変更だった

0
Posted at

はじめに

みなさんこんにちは。
Github Actions を使っていますでしょうか?

GitHub では、OIDC 周りにおいて 2026 年 7 月 15 日に仕様変更が行われました。

私はこの仕様変更に気付かないまま、この日以降に新規作成したリポジトリで GitHub Actions を設定し、
これまでと同じ手順で aws-actions/configure-aws-credentials@v6.1.0 を実行したところ、
AssumeRoleWithWebIdentity のエラーが発生し、AWS の IAM ロールを Assume Role できませんでした。

エラー発生当初は、IAM ロールや OIDC Provider の設定に問題があるのではと考え、AWS 側を中心に調査を進めていました。
しかし、最終的に判明したのは、GitHub の OIDC Subject Claim (sub) の仕様変更が根本原因でした。

もちろん、IAM ロールの Trust Policy が新しい仕様に対応していなかったことが直接の原因ですが、その背景には GitHub の仕様変更がありました。

本記事では、調査の過程で分かったことや原因、そして解決方法について紹介します。
同じエラーで困っている方が、原因の特定と解決までの時間を少しでも短縮できれば幸いです。


対象読者

  • GitHub Actions を業務またはプライベートで利用している方
  • GitHub Actions から AWS の IAM ロールを引き受けるために aws-actions/configure-aws-credentials を利用している方
  • Could not assume role with OIDCNot authorized to perform sts:AssumeRoleWithWebIdentity のエラーで困っている方

使用した Github

今回の検証では、以下の Github リポジトリを使用しました。
https://github.com/nkserveren26/test_github_actions_assume_role

Github Actions ワークフローの内容は以下です。

workflow.yml
name: Test Assume Role

on:
  push:
    branches:
      - main

jobs:
  s3ls:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: aws-actions/configure-aws-credentials@v6.1.0  # ← エラーが発生したアクション
        with:
          aws-region: ap-northeast-1 # リージョンを指定
          role-to-assume: ${{ secrets.ASSUME_ROLE_ARN }} # GitHub Secrets に登録した IAM ロールの ARN

      # S3 バケット一覧を取得
      - run: aws s3 ls 

今回、エラーが発生したのは aws-actions/configure-aws-credentials@v6.1.0 の実行時です。

この Action では、GitHub Actions が発行した OIDC トークンを使用して、AWS の IAM ロールを Assume Role します。

その後の aws s3 ls は、Assume Role に成功した後に AWS リソースへアクセスできることを確認するために実行しています。

aws-actions/configure-aws-credentials@v6.1.0 とは?

aws-actions/configure-aws-credentials@v6.1.0 は、GitHub Actions で AWS の認証情報を設定するための Action です。

今回のように、GitHub Actions から AWS の IAM ロールを Assume Role する用途で利用できます。

GitHub Actions から AWS へ認証する方法はいくつかありますが、aws-actions/configure-aws-credentials では、OIDC(OpenID Connect)を利用して IAM ロールを Assume Role できます。

OIDC(OpenID Connect)とは?

OIDC は、OAuth 2.0 をベースとした認証プロトコルです。

簡単に説明すると、認証を行う側(IdP: Identity Provider)と、認証結果を利用する側(サービス)を事前に信頼関係で結び、IdP が発行した ID Token を利用してサービス側で認証・認可を行う仕組みです。

今回のケースでは、以下のような関係になります。

GitHub
  │
  │ OIDC Token を発行
  ▼
GitHub Actions
  │
  │ OIDC Token を AWS STS に提示
  ▼
AWS STS
  │
  │ Token を検証
  │ IAM Role の Trust Policy を確認
  ▼
IAM Role

aws-actions/configure-aws-credentials@v6.1.0 は、GitHub Actions 上で OIDC Token を取得し、その Token を利用して AWS STS の AssumeRoleWithWebIdentity API を呼び出します。

つまり、IAM ユーザが発行するアクセスキーを GitHub Secrets に保存するのではなく、GitHub Actions の実行時に発行された OIDC Token を利用して、一時的な AWS 認証情報を取得することができます。

この認証情報には有効期間が設定されているため、長期間利用可能なアクセスキーを GitHub Secrets に保存する方法と比較して、よりセキュアに AWS へアクセスできます。

AssumeRoleWithWebIdentity で取得する AWS 認証情報の有効期間について
AssumeRoleWithWebIdentity で取得する AWS 認証情報には有効期間が設定されています。

IAM ロールの「最大セッション時間」で上限を設定でき、デフォルトは 1 時間、最大 12 時間です。

実際のセッション時間は、この上限の範囲内で AssumeRoleWithWebIdentity 実行時に指定できます。

AWS 側では、OIDC を利用して GitHub Actions から IAM ロールを AssumeRoleWithWebIdentity するために、事前に以下の設定が必要です。

  • IAM OIDC Provider の作成
  • IAM ロールの作成
    • Trust Policy の設定

IAM OIDC Provider の作成

IAM OIDC Provider は、AWS と OIDC の IdP との間に信頼関係を設定するためのリソースです。
IAM OIDC Provider を作成することで、AWS は指定した OIDC IdP が発行したトークンを信頼します。

ただし、IAM OIDC Provider を作成しただけでは AWS のリソースを操作する権限は付与されません。
実際にどの AWS リソースを操作できるかといった権限は、別途 IAM ロールなどで付与する必要があります。

GitHub Actions で GitHub の OIDC を利用して IAM ロールを Assume Role するため、今回は以下の内容で IAM OIDC Provider を作成します。

  • プロバイダタイプ: OpenID Connect
  • プロバイダのURL: https://token.actions.githubusercontent.com
  • 対象者: sts.amazonaws.com

IAM ロールの作成

次に、GitHub Actions から Assume Role する IAM ロールを作成します。

IAM ロールには、主に以下の2種類のポリシーがあります。

  • 信頼ポリシー(Trust Policy)
    • どの主体がこの IAM ロールを Assume Role できるかを定義します。
  • Permissions Policy
    • この IAM ロールを Assume Role した後に、どの AWS リソースを操作できるかを定義します。

今回は、GitHub Actions からこの IAM ロールを Assume Role できるようにするため、Trust Policy を設定します。
Trust Policy では、GitHub Actions が発行する OIDC Token の subaud を条件として指定し、信頼する対象を限定します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::<AWSアカウントID>:oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringLike": {
                    "token.actions.githubusercontent.com:sub": "repo:<ユーザー名>/<リポジトリ名>:*"
                },
                "StringEquals": {
                    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
                }
            }
        }
    ]
}

※ この時点では、従来の GitHub OIDC Subject (sub) Claim の形式を前提として Trust Policy を設定しています。この点が、今回発生したエラーの重要なポイントになります。


以上の事前準備を行ったうえで、GitHub Actions を実行しました。

これで問題なく Assume Role できるはずでしたが、aws-actions/configure-aws-credentials@v6.1.0 の実行時にエラーが発生しました。

ここからは、実際に発生したエラーの内容と、原因を特定するまでの調査について説明します。

発生したエラー

実際のエラーメッセージは以下です。

Run aws-actions/configure-aws-credentials@v6.1.0
Assuming role with OIDC
Assuming role with OIDC
Assuming role with OIDC
Assuming role with OIDC
Assuming role with OIDC
Assuming role with OIDC
Assuming role with OIDC
Assuming role with OIDC
Assuming role with OIDC
Assuming role with OIDC
Assuming role with OIDC
Assuming role with OIDC
Error: Could not assume role with OIDC: Not authorized to perform sts:AssumeRoleWithWebIdentity

aws-actions/configure-aws-credentials@v6.1.0 で、sts:AssumeRoleWithWebIdentity による IAM ロールの Assume Role が許可されず、エラーが発生していることが分かります。
このエラーメッセージを頼りに原因調査を行いました。

原因調査

IAM ロールの確認

まず、IAM ロールの信頼ポリシーの設定内容に不備がないか確認しました。
(IAM ロールに記載の nkserveren26 はユーザ名、test_github_actions_assume_role はリポジトリ名です)

見たところ、GitHub Actions から AWS の IAM ロールを Assume Role する手順を紹介している技術記事に記載の内容と変わりはありませんでした。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::819628840011:oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
                    "token.actions.githubusercontent.com:sub": "repo:nkserveren26/test_github_actions_assume_role:ref:refs/heads/main"
                }
            }
        }
    ]
}

OIDC Provider を確認

次に OIDC Provider の設定内容を確認しました。
これも特に間違いはなさそうです。

CloudTrail を確認

次に CloudTrail の AssumeRoleWithWebIdentity イベントのログを確認しました。
CloudTrail のログでは、エラーメッセージに加えて認証対象の sub 等、より細かい情報を確認することができます。

AssumeRoleWithWebIdentity イベントログの記録先リージョンは、aws-actions/configure-aws-credentials@v6.1.0 アクションの aws-region で指定したリージョンになります。

今回問題が起きたケースでは、東京リージョンを指定していたので、東京リージョンにログが記録されます。

で、当該イベントのログをマネジメントコンソール上で確認すると、
username の部分には、OIDC の sub Claim に対応する値が記録されています。
ここが IAM ロールの信頼ポリシーで指定した形式と異なっていました。
(ユーザ名やリポジトリ名の後に @数字 が付いている??)

repo:nkserveren26@74305911/test_github_actions_assume_role@1304071215:ref:refs/heads/main

改めて IAM ロールの信頼ポリシーを確認します。
Condition の token.actions.githubusercontent.com:sub で指定する値と、
上記 CloudTrail ログの username に記載の値が一致していません。
(CloudTrail ログの username に記載されている @数字 がない)

両者の値が一致していないと、対象のリポジトリ(ブランチを指定するならブランチ名も含め)で実行する Github Actions アクションに対する Assume Role 権限を付与したことにならず、今回のようなエラーが出ます。

しかし、Github Actions での、OIDC を使った IAM ロールの Assume Role の手順を紹介する記事の多くでは、IAM ロールの信頼ポリシーで指定する token.actions.githubusercontent.com:sub には、上記画像の形式で値を指定しています。

これは一体どういうことなのか・・・。

GitHub の OIDC Subject Claim (sub) の仕様が変わった

実は、2026 年 7 月 15 日に、GitHub の OIDC Subject Claim (sub) の仕様変更が行われました。
この仕様変更により、GitHub Actions が発行する OIDC トークンの Subject (sub) Claim には、所有者名・リポジトリ名に加えて、それぞれの Immutable な ID(Organization ID / User ID、Repository ID)が含まれるようになりました。

・変更前

repo:my-org/my-repo:ref:refs/heads/develop

・変更後

repo:my-org@123456789/my-repo@987654321:ref:refs/heads/develop

変更されたのは、所有者 (ユーザ or Organization) とリポジトリの部分であり、それぞれに Immutable な ID が付与されるようになりました。

Github の「Configuring OpenID Connect in Amazon Web Services」に、本仕様変更に関する以下の記載があります。

For repositories created after July 15, 2026, or that have opted in to immutable subject claims, the sub claim includes immutable owner and repository IDs (not available on GitHub Enterprise Server). Make sure your trust policy matches the format your repository uses.

なぜ仕様変更されたのか

この仕様変更の背景には、OIDC の sub に求められる「一意性」と「再利用されないこと」があると考えられます。

OIDC の仕様の技術文書である「OpenID Connect Core 1.0」に、sub について以下のように記載されています。

A Subject Identifier is a locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client.

この記載が示すように、sub は同じ Issuer(発行者)の中で一意であり、かつ一度割り当てられた値が別の主体(ユーザ、Organization、リポジトリ)に再利用されてはならないことが仕様として定義されています。

仕様変更前の Github OIDC の sub は以下でした。
(以下は Organization 内で作成したリポジトリの場合)

repo:my-org/my-repo:ref:refs/heads/develop

例えば、A社の Organization 名が「my-org」で、リポジトリ名が「my-repo」である場合、
このリポジトリの OIDC sub は上記となります。

では、A社が Github の使用を辞めて、Organization とリポジトリを削除し、その後 B 社が新たに Github 上「my-org」という名前で Organization を作成し、この Organization に「my-repo」という名前でリポジトリを作成したとします。

この時、このリポジトリの OIDC sub は以下となります。

repo:my-org/my-repo:ref:refs/heads/develop

A社で使用していたリポジトリと、Organization 名・リポジトリ名が同じになるため、OIDC の sub も同じ値になります。
つまり、一度発行された sub が別の主体で再利用されていることになります。
これは OIDC の sub に求められる「locally unique and never reassigned」を満たしません。

このように、sub の一意性を保ち、再利用されることを防ぐために、このような仕様変更がされたと考えられます。
Github のリファレンスにもコレに関する記載がされています。

The OpenID Connect (OIDC) specification requires subject (sub) claims to be locally unique and never reassigned. Previously, the default sub format used only organization and repository names. If a namespace was recycled, a different owner could create the same subject value.
To help prevent this scenario, repositories created after July 15, 2026 now use an immutable default subject format that includes both the owner ID and repository ID.

適用対象リポジトリ

Github リファレンスの上記記載の通り、以下の条件に該当するリポジトリにおいて、この仕様変更が適用されます。

  • 2026 年 7 月 15 日以降に作成されたリポジトリ
  • 2026 年 7 月 15 日以前から存在したリポジトリで、「Use immutable subject claim」が有効化されているリポジトリ
    • 2026 年 7 月 15 日以降に作成されたリポジトリでは、この設定が有効化されています。

今回使用したリポジトリは 2026 年 7 月 15 日以降に作成したリポジトリだったため、新しい Immutable Subject Claim の形式が適用されていました。

一方、IAM ロールの Trust Policy には従来の sub の形式を指定していました。

そのため、GitHub Actions が実際に送信した sub と IAM ロールの Trust Policy に設定した sub が一致せず、AssumeRoleWithWebIdentity が失敗していました。

解決方法

今回の事象は、GitHub Actions が発行する OIDC Token の sub と、IAM ロールの信頼ポリシーに指定した sub が一致していないことが原因でした。

そのため、IAM ロールの信頼ポリシーに、GitHub リポジトリで使用されている sub を指定することで解決できます。

まず、対象リポジトリで GitHub が使用している sub を確認します。

Github のリポジトリのページにアクセスし、[Settings] > [Actions] > [OIDC] に遷移します。
[Default subject claim prefix] に sub が記載されているので、これをメモ帳等に控えておきます。

sub を確認したら、IAM ロールの信頼ポリシーを修正します。
token.actions.githubusercontent.com:sub に、↑で確認した sub を指定します。
特定のブランチを指定する場合は、以下のように指定します。
(以下は main ブランチを指定した場合)

repo:<ユーザ名 or Organization 名>@<User ID / Organization ID>/<リポジトリ名>@<repository ID>:ref:refs/heads/main

IAM ロールを修正後、本記事の「使用した Github」に記載の Github Actions ワークフローを実行します。
aws-actions/configure-aws-credentials@v6.1.0 でエラーが起きず、正常にワークフローが実行されました。

まとめ

2026 年 7 月 15 日以降に新規作成したリポジトリで AssumeRoleWithWebIdentity が失敗した場合は、まず OIDC Token の sub の形式を確認しましょう。

GitHub の OIDC Subject Claim (sub) は、2026 年 7 月 15 日以降に作成されたリポジトリなどを対象に、Owner ID と Repository ID を含む Immutable な形式に変更されています。

IAM ロールの信頼ポリシーに従来の sub 形式を指定している場合、GitHub Actions が実際に使用する sub と一致せず、AssumeRoleWithWebIdentity が失敗する可能性があります。

この場合は、GitHub リポジトリの [Settings] > [Actions] > [OIDC] から使用されている sub を確認し、その値に合わせて IAM ロールの信頼ポリシーを修正することで解決できます。

参考資料

https://zenn.dev/fusic/articles/48620c1c798ece
https://qiita.com/Mouflon_127000/items/d4c2d942d552b0051cb1
https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-aws?ref=nalth.is
https://openid.net/specs/openid-connect-core-1_0-errata1.html
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html
https://dev.classmethod.jp/articles/extending-the-expiration-of-the-temporary-credential-acquired-by-assumerole/

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?