GitHub ActionsをOIDCへ移行する理由とは？秘密情報を減らす進め方

なぜ GitHub Actions を OIDC へ移行するのか

長期シークレットを置き続ける構成そのものが事故面になります

GitHub Actions を OIDC へ移行する理由を一言で言うと、クラウド認証情報を GitHub Secrets に長く置き続ける構成を減らすためです。GitHub Docs の OpenID Connect 解説↗でも、クラウド側が GitHub から発行されたトークンを直接信頼できるようになるため、長期シークレットを保存しなくてよい点が大きな利点として示されています。

ここでいう長期シークレットとは、アクセスキー、サービスプリンシパルのシークレット、固定鍵ファイルのように、誰かがコピーでき、期限管理も必要で、失効や再発行の運用負荷が高い認証情報です。既存のサービスアカウントのセキュリティでも触れているとおり、認証情報の事故は「漏れたら終わり」というより、長く生きる資格情報が複数の場所に残ることで被害範囲が広がります。

GitHub Actions からクラウドへ接続するジョブは、ビルド、デプロイ、コンテナ公開、インフラ更新など、本番系の権限を持ちやすい領域です。そのため、長期シークレットを GitHub Secrets に置いたまま運用すると、漏えい、誤設定、退職者や委託先の棚卸し漏れ、fork や複製 workflow の扱いといった複数の運用問題が重なります。OIDC 移行は、単なる新しい認証方式ではなく、長期資格情報を減らす運用改善として捉えた方が実務に合います。

ただし、OIDC に変えれば何でも安全になるわけではありません。GitHub 側のトークン発行条件が広すぎたり、クラウド側の信頼条件が雑だったり、旧シークレットを削除しなかったりすると、事故面は残ります。つまり移行の主役は「OIDC を入れたこと」ではなく、何を信頼し、何を信頼しないかを明文化したことにあります。

既存のCI/CD パイプライン攻撃や公開リポジトリの情報漏えいを読むと分かるように、開発基盤の事故は認証方式だけで完結しません。GitHub Actions を OIDC へ移行する価値は大きいですが、それは長期シークレットを減らす入口であり、runner、権限、公開面の見直しまでつながって初めて効果が出ます。

移行前に先に決めるべき信頼境界は何か

どの workflow に OIDC トークン発行を許すかを絞る必要があります

GitHub Actions で OIDC を使うには、workflow または job に「id-token: write」権限を与える必要があります。これは GitHub がトークンを発行できるようにする権限であり、設定自体は難しくありません。しかし実務上は、技術的に有効化できることと、どのジョブへ有効化してよいかは別問題です。

たとえば、すべての workflow に一律で OIDC 発行権限を付けると、クラウド接続が不要なジョブまでトークンを要求できる状態になります。これは便利ですが、将来の workflow 追加や reusable workflow の呼び出しが増えたときに、どこまでクラウド認証が必要なのかが曖昧になります。移行前には、ビルド専用、検証専用、本番配備専用のように、ジョブの役割で線を引くところから始めるべきです。

「どのリポジトリ・ブランチ・環境か」を subject 条件で狭めます

GitHub Docs のOpenID Connect reference↗では、クラウド側で確認できる claim として repository、ref、environment、audience などが説明されています。ここで重要なのは、クラウド側の信頼ポリシーや federated identity credential を作るときに、sub claim を広く取りすぎないことです。

実務でよくある失敗は、「この GitHub 組織のリポジトリなら大丈夫だろう」と広く許可してしまうことです。しかし GitHub Actions OIDC の移行で本当に必要なのは、どのリポジトリの、どの参照先の、どの環境からの実行かまで絞ることです。本番 deploy 用ロールと検証環境 deploy 用ロールを分けずに subject 条件を広くすると、短命トークンでも被害面積は広いままです。

GitHub Actions を OIDC へ移行するときは、「シークレットがなくなる」話より先に、信頼する実行条件をどこまで言語化できるかを確認してください。ここが曖昧だと、OIDC の導入後も「誰がどこまで deploy できるか」を説明できません。

runner の信頼モデルは OIDC と別で見直す必要があります

OIDC はクラウド認証の方式を改善しますが、runner 自体の信頼問題を解決するわけではありません。特に self-hosted runner では、同じ runner に複数のリポジトリや環境のジョブを載せていると、ローカルファイル、キャッシュ、既存資格情報、周辺ツールが思わぬ共有面になります。OIDC へ移行しても、runner が広く共有されている状態では十分ではありません。

Azure Login の公式説明でも、public repository の self-hosted runner で managed identity を使うと危険になり得る旨が警告されています。これは Azure 固有の問題というより、実行基盤の信頼境界が粗いままでは、OIDC の利点が薄れることを示しています。したがって移行前には、GitHub-hosted runner で済むジョブか、self-hosted runner が必要でもどのリポジトリまで共有を許すかを分けて考える必要があります。

AWS・Azure・Google Cloud では何が違うのか

AWS では IAM ロールを環境ごとに分ける発想が重要です

GitHub Docs のAWS 向け OIDC 設定↗では、IAM ロールの trust policy で audience と subject を確認する考え方が示されています。ここで重要なのは、GitHub Actions OIDC の導入を「AWS に login できるようにする作業」で終わらせず、本番用ロールと検証用ロールを分ける発想にすることです。

AWS はロールの使い分けが柔軟なぶん、最初に一つのロールへ権限を寄せると後から分解しにくくなります。GitHub Actions を OIDC へ移行するなら、最初から「どの workflow がどのロールを引き受けるか」を固定し、ロールごとに対象の ref や environment を絞った方が運用しやすくなります。

Azure は OIDC を推奨していても、運用上の変数整理が残ります

Microsoft Learn と Azure Login Action の公式説明では、OIDC での認証が推奨されています。Azure 側では federated identity credential を用意し、GitHub 側の workflow に「id-token: write」を与えたうえで、client-id、tenant-id、subscription-id を指定して login します。つまり長期 secret は減らせますが、管理対象の変数が完全に消えるわけではありません。

ここでよく起きる誤解は、「OIDC へ移行したので GitHub 側の管理対象はゼロになる」というものです。実際には、接続先の subscription や tenant の整理、cloud 環境ごとの audience、ログの出力制御など、別の運用論点が残ります。したがって Azure では、認証 secret の削減に加えて、環境単位の変数管理とログ設計を同じ変更セットで考える必要があります。

Google Cloud は provider 設計と impersonation の分離が鍵になります

GitHub Docs のGoogle Cloud 向け OIDC 設定↗では、workload identity federation と service account impersonation を組み合わせる流れが説明されています。Google Cloud では provider 側で属性をどう受け取るか、service account 側で何をさせるかを分けて設計できるため、信頼条件と実行権限を別々に整理しやすいのが特徴です。

その反面、provider、attribute mapping、service account、impersonation の責務が混ざると設計が分かりにくくなります。GitHub Actions の OIDC 移行では、どの repository 条件を provider で受け、どの権限を service account へ与えるかを分けて考えた方が、監査や将来の切り替えも楽になります。

GitHub Actions OIDC 移行の進め方

最初に「いま何が残っているか」を把握しないと移行しにくくなります

GitHub Actions の OIDC 移行は、workflow の書き換えから始めるより、現行の secret 運用の棚卸しから始めた方が成功しやすくなります。どの workflow が AWS、Azure、Google Cloud へ接続しているのか、どのシークレットが deploy 用で、どれがイメージ push 用で、どれが検証用なのかが見えないままでは、切り替え対象と例外を分けられません。

ここで役立つのは「シークレットの一覧」ではなく、ジョブと権限の対応表です。GitHub Secrets 名だけ並べても、どのジョブのどの操作に使われているかが抜けると、OIDC へ移したあとに不要なシークレットが残ります。まずは用途単位で切り分けてください。

並走期間を短くし、削除日を先に決めると戻りにくくなります

OIDC 移行では、新旧の認証方式を少し並走させて比較試験すること自体は有効です。ただし、その並走期間が長いと「まだ動いているから」と旧シークレットが残り続けます。ここで重要なのは、OIDC 化より先に旧シークレットの削除日と例外条件を決めることです。

たとえば本番 deploy は OIDC に切り替え、緊急ロールバックだけは期限付き例外で旧シークレットを残す、といった形なら運用できます。一方で「いったん両方残しておく」は、最も戻りやすい運用です。GitHub Actions を OIDC へ移行するなら、成功条件と同じくらい、消す条件を先に決めておいた方がよいです。

監査ログの読み方まで決めると移行が定着しやすくなります

OIDC の導入自体は数ファイルの変更で終わることもありますが、運用に定着するかどうかは、失敗時に誰が何を追えるかで決まります。GitHub Actions のログだけでは足りず、クラウド側の認証ログ、ロール引き受けログ、service account impersonation の記録まで合わせて見られるかを確認してください。ここが決まっていると、切り替え後に問題が起きても「OIDC が悪い」ではなく、どの条件がずれていたかを特定しやすくなります。

見落としやすい運用上の落とし穴

fork 由来の workflow と reusable workflow の扱いを曖昧にしない

GitHub Actions の OIDC 移行で見落としやすいのが、fork 由来の workflow と reusable workflow の扱いです。トークン発行条件を repository 名だけで広く取ると、想定していない呼び出し元にもクラウド認証の道を開きやすくなります。OIDC は短命トークンであっても、広い呼び出し条件を許してよい理由にはなりません。

とくに reusable workflow を共通化している組織では、呼び出し元の repository と実際にクラウド認証を行う job の関係を説明できる状態が必要です。ここが曖昧なままだと、信頼ポリシーだけ見ても本当に許してよい実行か判断しにくくなります。

OIDC にしても過剰権限のロールは危険なままです

GitHub Actions を OIDC へ移行すると、長期シークレットの漏えいリスクは減ります。しかし deploy ロールや service account の権限自体が広すぎるなら、短命トークンでも被害は大きくなります。つまり OIDC は「安全な資格情報の渡し方」を改善するものであって、過剰権限を正当化する仕組みではありません。

そのため、OIDC 移行と同時にロール分離を見直した方が効果が高くなります。本番 deploy、artifact push、state 更新、検証環境の自動反映を一つの権限へまとめているなら、認証方式の変更だけで満足せず、どこまでを同じ job に任せるべきかも見直してください。

旧シークレットを残したままでは「移行済み」に見えても実態は変わりません

現場では「OIDC の workflow は動いているので移行完了」と見なされることがあります。しかし GitHub Secrets に旧アクセスキーや client secret が残っていれば、実態としては長期資格情報の事故面が残ったままです。切り替え後も誰も削除に踏み込めない組織では、新しい認証が増えただけになりやすいです。

そのため、移行完了の定義は「OIDC の job が成功したこと」ではなく、「不要な長期シークレットが削除され、例外が台帳化されたこと」に置いた方が実務でぶれません。ここまでできて初めて、GitHub Actions OIDC 移行の効果を説明できます。

公開面の粗さは OIDC では解決しません

OIDC へ移行すると、クラウド認証の安全性は上がります。しかし、deploy の結果として残る preview 環境、古い管理画面、用途不明のサブドメイン、公開 API ドキュメントのような外部公開面は別問題です。既存のソフトウェアサプライチェーン攻撃やサービスアカウントのセキュリティでも分かるように、認証経路を直しても、公開後の接点が見えなければ事故の芽は残ります。

GitHub Actions OIDC 移行は重要ですが、それは IAM と deploy 経路の改善です。どのホストが外へ出ているか、どの preview 環境が残っているか、どの API が意図せず公開されているかは、別の確認レーンで見直す必要があります。

GitHub Actions OIDC 移行で ASM診断 PRO を活かすなら

GitHub Actions の OIDC 移行では、クラウド認証情報を長期シークレットで持ち続ける構成を減らせます。しかし、ASM診断 PRO が効くのはその先です。deploy 経路が安全になっても、preview 環境、古い staging、使い終わったホスト、想定外に露出した API、過去の検証画面が外に残っていれば、公開面としての事故リスクは残ります。つまり OIDC 移行は認証経路の改善であり、外から見える接点の整理とは別工程です。

ASM診断 PRO は、GitHub Actions の OIDC 設定や IAM ロールの代替ではありません。ですが、OIDC へ移行したあとに「何が外へ残っているか」を確認する役割とは相性が良いです。たとえば、旧 deploy フローで作られた preview ホストが残っていないか、使い終わったサブドメインが生きていないか、管理画面や認証導線が意図せず公開されていないかを外側から洗い直すと、OIDC 移行の効果を認証情報の削減だけでなく公開面の整理まで広げやすくなります。

もし今、GitHub Actions OIDC 移行を進めているなら、切り替え後の完了条件に「不要な長期シークレットを削除したこと」だけでなく、「旧 deploy 由来の公開面を確認したこと」も入れてください。移行後の見直しで外部公開資産を洗い出せれば、認証経路の改善と公開面の改善を一つの変更セットとして締めやすくなります。GitHub Actions の OIDC 移行を、本当に事故面の縮小へつなげるには、最後に外側からの確認を足すことが重要です。

よくある質問（FAQ）

GitHub Actions を OIDC へ移行すると GitHub Secrets は完全になくなりますか

クラウド認証の長期シークレットは大きく減らせますが、環境名や subscription ID のような管理用変数まで完全になくなるとは限りません。まずは認証 secret を減らすことが主目的です。

id-token 権限を付ければ自動的に安全になりますか

なりません。クラウド側の信頼条件が広すぎたり、runner の共有範囲が雑だったり、旧シークレットを残したままだと効果は薄れます。権限付与は出発点に過ぎません。

AWS、Azure、Google Cloud のどれが一番簡単ですか

どれも公式の導線はありますが、簡単さより「いま持っている IAM と運用へどう載せるか」で見た方が失敗しにくくなります。どのクラウドでも環境分離と信頼条件の絞り込みは必要です。

self-hosted runner でも OIDC は使うべきですか

使う価値はありますが、runner 自体の信頼境界を別で見直す必要があります。公開 repository や広い共有 runner では、OIDC だけで安全になったとは言えません。

移行後に最初に確認すべきことは何ですか

旧シークレットが削除されているか、クラウドログで想定した条件だけが使われているか、旧 deploy 由来の preview 環境や公開面が残っていないかの 3 点です。

まとめ

GitHub Actions を OIDC へ移行する最大の理由は、クラウド認証情報を長期シークレットとして持ち続ける構成を減らせることです。GitHub Docs が示すように、OpenID Connect を使えば、workflow 実行時に発行されるトークンをクラウド側が直接信頼できるため、固定のアクセスキーや client secret を GitHub Secrets に置く必要を小さくできます。これは認証情報漏えいの可能性を下げるだけでなく、棚卸し、失効、委託先見直しの負荷を減らすうえでも意味があります。

ただし、移行の成否を分けるのは OIDC を有効化したかどうかではありません。どの workflow に id-token 発行を許すか、どのリポジトリ、どのブランチ、どの環境からクラウド認証を許すか、self-hosted runner の共有範囲をどう扱うか、旧シークレットをいつ削除するかまで決めて初めて、信頼境界が締まります。短命トークンへ変えるだけでは、広すぎる権限や粗い runner 運用は残るため、移行は必ず IAM、実行基盤、ログ設計とセットで考える必要があります。

さらに見落としやすいのは、OIDC 移行が認証経路の改善であって、公開面の改善そのものではない点です。GitHub Actions 側の認証が安全になっても、旧 deploy 由来の preview 環境、古い staging、意図しない公開 API、放置されたサブドメインが外に残っていれば事故面は続きます。だから GitHub Actions OIDC 移行は、長期シークレット削減、信頼条件の明文化、旧シークレット削除、そして外側からの公開面確認までを一つの流れにして進めてください。ここまでそろえて初めて、認証方式の変更が実際の事故面縮小へつながります。