Docker HubがGitHub ActionsとのOIDC連携に対応、長期有効なトークン不要でセキュアな認証が可能に
要点
- 米Dockerは、GitHub ActionsのワークフローからDocker Hubへ安全にアクセスするための「OpenID Connect（OIDC）」接続のサポートを開始した。
- 本機能を利用することで、GitHubのリポジトリシークレットに永続的なアクセストークンを保管する必要がなくなり、短時間のみ有効なトークンで認証が行えるようになる。
- 利用対象は、Docker TeamやDocker Businessなどの一部有料プランを契約する組織、および特定のオープンソース支援プログラムの参加組織となる。
- OIDCの連携設定はDockerの管理コンソールから行い、ワークフローファイルへの軽微な修正だけで段階的に移行できる。
- 移行後も従来のアクセストークンは機能し続け、コンテナイメージのビルドやプッシュといったその後のプロセスに変更はない。
リード文
米Dockerは2026年7月31日（現地時間）、GitHub ActionsのワークフローからDocker Hubにアクセスする際の認証手段として、OpenID Connect（OIDC：ID連携のためのオープン標準規格）接続の正式サポートを開始したことをブログで発表した。本機能はDockerのOrganization（組織）アカウント向けに提供されるもので、DockerのGreg Mondello氏およびDan Stelzer氏によって紹介された。これにより、開発者はCI/CD（ソフトウェアのビルドやテスト、デプロイを自動化する仕組み）のパイプラインに永続的なアクセスキーを保管する必要がなくなり、認証情報の漏洩リスクや管理に伴う人的コストを大幅に削減できるようになる。
従来の認証方法が抱えるセキュリティ上の課題
これまで、GitHub ActionsのワークフローからDocker Hubに対してコンテナイメージ（アプリケーションとその実行に必要なファイルをまとめたパッケージ）のプッシュやプルを行う際、認証手段として個人アクセストークン（PAT）や組織アクセストークン（OAT）が用いられてきた。これらの認証情報は、GitHubのリポジトリ設定内にある暗号化シークレット領域に保存されるのが一般的だ。
しかし、これらのトークンは有効期限が非常に長く設定されているため、定期的なローテーション（新しいトークンを再発行する作業）が必要となる。パイプラインやプロジェクトの規模が拡大するにつれて、登録されているすべてのトークンを追跡し、手動で更新し続ける作業は繁雑化し、実用的にスケールしないという課題があった。実際、更新されずに長期間放置されたトークンは、企業のセキュリティ監査において頻繁に指摘を受ける対象となっている。
さらに、これらの永続トークンが万が一外部に漏洩した場合、その事実を検知して誰かがトークンを手動で失効させるまでの間、第三者によって非公開リポジトリからイメージを勝手にダウンロードされたり、悪意のあるイメージをアップロードされてしまうといった、重大なセキュリティインシデントに繋がる危険性も抱えていた。
短期間で失効する「OIDC接続」の認証メカニズム
今回新たに導入されたOIDC接続では、永続的なパスワードやAPIキーを使用しない認証フローを実現している。OIDCによる認証は以下の流れで行われる。
- IDトークンの発行: GitHub Actionsのワークフローがトリガーされると、GitHubは実行中のリポジトリやブランチ、環境情報などのメタデータを含んだ、電子署名付きのJWT（JSON形式で安全に情報を転送するためのトークン規格）と呼ばれるIDトークンを生成し、発行する。
- トークンの送信: ワークフロー内で実行されるDocker公式のログインアクション（docker/login-action）が、このIDトークンをDocker側のシステムに送信する。
- 署名とルールの検証: トークンを受け取ったDockerは、GitHubが公開している鍵を用いて署名の正当性を検証する。同時に、Dockerの管理者用コンソールで事前に設定されたアクセス制御ルール（ルールセット）に適合しているかを確認する。
- 一時的トークンの発行: トークンがルールに合致している場合、Dockerは指定されたリソースへのアクセス権限を持つ、有効期限が極めて短いアクセストークンを発行してワークフローに返却する。このトークンは数分程度で自動的に無効化され、後から再利用することはできない。
- 認証完了と操作の実行: ログインアクションはこの一時的なトークンを使ってDocker Hubにログインし、以降のプッシュやプル、ビルドといったコンテナ操作を通常通り実行する。
この一連のやり取りには、パスワードやAPIキーなどの固定された認証情報は一切関与しない。Dockerは、この仕組みがすでにAmazon Web Services（AWS）の「OIDC for GitHub Actions」や、Google Cloud Platform（GCP）の「Workload Identity Federation」などの主要クラウドサービスで採用されているものと同様のセキュリティパターンであり、それをコンテナレジストリの認証にも応用したものだと説明している。
OIDC連携を有効にするための具体的な設定方法
OIDC接続の導入手順は、Dockerの管理ポータル「Docker Home」での設定と、GitHub Actionsのワークフロー定義ファイル（YAML形式）の編集という、大きく分けて4つの移行ステップから構成される。
ステップ1: Docker Homeでの接続作成
まず「Docker Home」にログインし、設定を行いたい組織アカウントを選択してOIDC接続の設定画面に移動する。「Create OIDC connection」を選択し、どのリポジトリやブランチからDocker Hubの特定リソースへのアクセスを許可するかを定義する「ルールセット」を作成する。1つの接続につき最大5つのルールセットを設定でき、安全性を高めるために、特定のレポジトリやブランチにアクセス権限を絞り込む（ピン留めする）ことが強く推奨されている。ルールセットで使用するマッチングパターンの指定方法は以下の通りだ。
repo:my-org/my-repo:ref:refs/heads/main: 特定のリポジトリの「main」ブランチからのみアクセスを許可する。repo:my-org/my-repo:ref:refs/heads/release-*: 特定のリポジトリ内の「release-」から始まるすべてのリリースブランチからアクセスを許可する。repo:my-org/my-repo:*: 対象リポジトリのすべてのブランチからのアクセスを許可する。repo:my-org/*: 組織内のすべてのリポジトリからのアクセスを許可する（セキュリティの観点から推奨されていない）。
設定が完了すると、接続IDが生成されるため、これをコピーしておく。なお、2026年7月15日以降に新規作成されたGitHubリポジトリでは、デフォルトのサブジェクト値（リポジトリを識別する文字列）に「不変の識別子（immutable identifiers）」が含まれる仕様に変更されているため、ルールの記述時にはこれに対応した記述にする必要がある。
ステップ2: ワークフローファイルの更新
次に、GitHub ActionsのワークフローYAMLファイルを書き換える。GitHubからOIDCトークンを取得してDockerに渡すための権限として、パーミッション設定に id-token: write と contents: read を明示的に追加する。
さらに、docker/login-action@v4（バージョン4.5.0以上）を使用するステップで、Docker組織名を username に設定し、先ほどコピーした接続IDを環境変数 DOCKERHUB_OIDC_CONNECTIONID に指定する。
ステップ3: 動作検証とトラブルシューティング
記述を変更したワークフローを実行し、正しくDocker Hubとの連携が行われ、動作が成功することを確認する。万が一認証エラーが発生した場合、Docker HomeのOIDC接続管理画面にある「Failures」タブを確認することで、送信されてきたクレーム値の詳細などからエラーの原因を診断できるようになっている。
ステップ4: 既存認証情報の削除
OIDCによる接続確認がすべて完了した後は、GitHubのリポジトリ設定に保存されている古いPATやOATを削除する。これで、パスワードなどの保管情報が一切存在しない状態での安全なパイプライン運用が確立される。
利用可能プランと移行における注意点
このGitHub Actions向けOIDC接続は、Docker Team、Docker Business、Docker Hardened Images（DHI：堅牢化されたコンテナイメージを提供するサービス）サブスクリプションを契約している組織、またはDocker Sponsored Open Source Program（DSOS：オープンソース開発を支援するプログラム）に登録されている組織が対象となる。
Dockerは、新機能の導入後も既存のPATやOATが直ちに無効化されるわけではなく、引き続き動作すると述べている。そのため、組織は既存のワークフローを一度に変更する必要はなく、それぞれの運用状況に合わせて段階的にOIDC接続へ移行することができる。また、この接続設定はあくまでも「認証」の仕組みを変更するものに過ぎないため、下流のコンテナイメージビルドやレジストリの動作などには一切影響を与えない。
一方で、今回のOIDC対応はGitHub Actionsを対象としたものである点に注意が必要だ。ローカル開発環境でのログインや、GitHub Actions以外のCIツールを使用する場合には、今後も従来通りPATやOATを用いる必要がある。Dockerは、他のCIプロバイダーからのサポート要望についても、利用者の需要に応じて対応を進める方針を示している。