GitHubリポジトリのOIDC設定でImmutable subject claimを有効化する

Last updated at 2026-09-21Posted at 2026-09-21

2026年7月15日以降に作成されたGitHubリポジトリではImmutable subject claimがデフォルトで使用されるようになっているので、本手順を行う必要はありません。

前提

GitHub Actionsでは、OIDC(OpenID Connect)を利用してAWSやGCPなどの外部サービスに対して認証を行うことができます。

OIDCによって発行されるトークンには、Claim（クレーム） と呼ばれる、そのトークンに関するさまざまな情報が含まれています。

その中の1つがsub(Subject)クレームです。簡単に言えば「このトークンの主体は誰なのか」を識別するための値です(英語文法でいうSubjectと同じですね)。GitHub Actionsでは、リポジトリ名やブランチ名などの情報を組み合わせてsubが生成されます。

例えば、octocat/my-repoリポジトリのmainブランチから実行されたWorkflowでは次のようなsubが使用されていました。

repo:octocat/my-repo:ref:refs/heads/main

AWSやGCPなどの認証先ではsubを条件として確認することで「このGitHubリポジトリの、このブランチから発行されたOIDCトークンだけを信頼する」といったアクセス制御を行うことが可能です。

仕様変更前のsub(サブジェクト)クレームは、以下のようになっていました。

repo:octocat/my-repo:ref:refs/heads/main

一見これでも良さそうに思えますが、以下のケースを想定してしましょう。

実際のところ、偶然このようなケースが発生することはめったにないでしょう。しかし、悪意を持っている人が意図的にこれを行ったらどうなるでしょうか？

ここで重要なのは、リポジトリ名とユーザー名が再利用されても、旧所有者(octocatさん本人)と新所有者(見知らぬ誰か)の間で生成されるサブジェクトクレームが同一になりうることです。

クラウドサービス側に、以前のsubを信頼する設定が残ったままだった場合、新しい所有者が同一のsubを持つOIDCトークンを発行し、その信頼関係を利用してクラウドリソースにアクセスできる可能性があります。

仕様変更後のsub(サブジェクト)クレームは、以下のようになりました。

repo:octocat@123456/my-repo@456789:ref:refs/heads/main

ユーザー名とリポジトリ名の後ろに数字が追加されていますね。これはユーザーIDとリポジトリIDを意味しています。ユーザーやリポジトリの名前は再利用されても、ユーザーIDやリポジトリIDは再利用されません。

これらのIDがあることで、先ほどのケースを想定した際でも、旧所有者と新所有者の間でサブジェクトクレームが同一になることはありません。それゆえ、懸念されていたクラウドリソースへの不正アクセスのリスクを抑えることができます。

Immutable subject claimを有効化することで、GitHub ActionsのOIDCトークンに含まれるsubにはユーザー名・リポジトリ名だけでなく、変更・再利用されないユーザーIDとリポジトリIDも含まれるようになります。

これにより、GitHubのユーザー名やリポジトリ名が変更・再利用された場合でも、別のユーザーやリポジトリが以前と同じsubを取得することを防ぐことができます。

2026年7月15日の仕様変更以降、新規に作成されたリポジトリではImmutable subject claimが標準で使用されますが、それ以前に作成されたリポジトリでは従来形式が維持されます。

そのため、GitHub ActionsからOIDCを利用してAWSやGCPなどの外部サービスへアクセスしている既存リポジトリでは、Immutable subject claimへの切り替えを検討するとよいでしょう。

Immutable subject claimへ切り替えるとsubの値が変更されるため、すでにクラウドサービス側でsubを認証条件として設定している場合は、先にそちらの設定を新しい形式へ対応させる必要があります。