サインイン

Docker組織向けにGitHub Actions用のDocker OIDC接続が利用可能になりました

投稿日 Jul 31, 2026
ダン・ステルツァー
グレッグ・モンデロとダン・ステルツァー
CI/CDパイプラインから保存された認証情報を排除する

要約：DockerはGitHub Actions向けにOpenID Connect （OIDC）をサポートするようになりました。ワークフローでは、保存されたPATやOATの代わりに、実行ごとに有効期限が切れるトークンを使用して認証を行うことができます。秘密を漏らす必要もないし、認証情報を漏らす必要もない。 

GitHub OIDC接続は、Docker Team、Docker Business、またはDocker Hardened Images（DHI）のサブスクリプションを持つ組織、およびDocker Sponsored Open Source Program（DSOS）に登録している組織が利用できます。

目次

  • 保存された認証情報に関する問題
  • 誰がこれを使うべきか
  • OIDC接続の仕組み
  • はじめ
  • 変わらないもの
  • 詳しく見る

GitHub ActionsとDocker間のOIDCトークン交換フロー

図の最終版

保存された認証情報に関する問題

Docker HubからイメージをプッシュまたはプルするすべてのGitHub Actionsワークフローは、GitHubシークレットとして保存されている個人アクセストークン（PAT）または組織アクセストークン（OAT）を使用して認証を行います。これらの資格は長期にわたり有効です。誰かが順番を入れ替えることを覚えておかなければならない。トークンが漏洩すると、レジストリへのアクセス権が付与され、プライベートなイメージの取得や悪意のあるイメージの送信が可能になります。そして、そのアクセス権は誰かが発見して取り消すまで持続します。回転は手動で行い、拡大縮小はできません。パイプラインが増えるにつれて、追跡が必要な認証情報も増え、古いトークンは監査でよく見つかる問題です。

誰がこれを使うべきか

  1. GitHubは、リポジトリ、ブランチ、環境、およびワークフロー実行に関するその他のメタデータをエンコードした署名付きIDトークン（JWT）を発行します。
  2. ワークフローはdocker/ login -actionを呼び出し、このトークンを Docker に提示します。
  3. Dockerは、トークンの署名をGitHubの公開鍵レジストリと照合し、管理コンソールで設定されたルールセットと照合します。
  4. トークンがルールセットに一致する場合、Dockerはそのルールセットで定義されたリソースにのみ有効な、有効期限の短いアクセストークンを返します。
  5. docker/login-action はこのトークンを使用して Docker Hub への認証を行います。そこから先は、docker pull、docker push、docker build コマンドは通常どおり動作します。

取引全体は、秘密情報、APIキー、アクセストークンなどを一切保存することなく行われます。有効期限の短いDockerアクセストークンは数分で期限切れとなり、再利用することはできません。

これは、AWSとGCPがクラウド リソースへのアクセスに既に使用しているパターンと同じです（ AWS OIDC for GitHub Actions 、 GCP Workload Identity Federation ）。Dockerはこれをコンテナレジストリへのアクセスに適用している。

はじめ

セットアップは、 Docker Homeへの一度限りの接続と、ワークフローYAMLへの小さな更新だけで完了します。

ステップ1：接続を作成する

Docker Homeにサインインし、所属組織を選択して、OIDC接続に移動します。「OIDC接続の作成」を選択し、どのリポジトリ、ブランチ、ワークフローがどのDocker Hubリソースにアクセスできるかを制御するルールセットを設定します。接続ごとに最大5つのルールセットを作成できます。ワークフローがOIDC交換をトリガーすると、Dockerは接続で定義されているすべてのルールセットに対してトークンをチェックします。ルールセットの条件が満たされた場合、Dockerはそのルールセットで設定されたパラメータに基づいてアクセスを許可します。

ルールセットは、OIDCのサブジェクトクレームを使用して、受信したトークンを照合します。セキュリティ上のベストプラクティスとして、特定のレポジトリやブランチをピン留めすることができます。

  • repo:my-org/my-repo:ref:refs/heads/main — 特定のリポジトリのメインブランチのみ
  • repo:my-org/my-repo:ref:refs/heads/release-* — すべてのリリースブランチ
  • repo:my-org/my-repo:* – このリポジトリのすべてのブランチ
  • repo:my-org/* — 組織内の任意のリポジトリ（非推奨）

作業が完了したら、接続IDをコピーしてください。

注：7月15、2026以降に作成されたGitHubリポジトリは、デフォルトのサブジェクトクレームに不変の識別子を使用します。例えば、repo:octocat@123456/my-repo@456789:ref:refs/heads/main。詳細はGitHubの変更履歴をご覧ください。

ステップ2：ワークフローを更新する

GitHub Actionsのワークフローを更新してください。<YOUR_CONNECTION_ID>前の手順で取得したIDに、 <YOUR_ORG_NAME> Docker組織名に置き換えてください。

permissions:
  contents: read
  id-token: write

steps:
    - name: Docker login                                                                                                                                                                 
      uses: docker/login-action@v4 # v4.5.0+                                                                                                                                                                
      with:                           
        username: <YOUR_ORG_NAME>
      env:                                                                                                                                                                               
        DOCKERHUB_OIDC_CONNECTIONID: <YOUR_CONNECTION_ID>

id-token : write 権限により、ワークフローは GitHub OIDC トークンを要求できます。DOCKERHUB_OIDC_CONNECTIONIDが設定されている場合、 docker/login-actionトークン交換とDockerログインを単一のステップで処理します。そこから、 docker pull、 docker push 、およびdocker buildコマンドは通常どおり機能します。接続が失敗した理由を診断するために使用できる、受信したクレームサブ値の詳細。

ステップ3：OIDC接続が正常に機能することを確認する

ワークフローを実行し、正常に完了することを確認してください。エラーが発生した場合は、OIDC接続ページの「障害」タブに受信クレームのサブ値の詳細が表示されます。この情報を使用して、接続が失敗した理由を診断できます。

ステップ4：保存されている認証情報を削除します

OIDCを使用してワークフローが正常に実行されることを確認したら、GitHubリポジトリのシークレットから古いPATまたはOATを削除してください。もう必要ありません。

移住チェックリスト

  • つながりを作る
  • ワークフローを更新
  • OIDC接続が正常に機能することを確認してください。
  • 保存されている認証情報を削除する

変わらないもの

  • 既存のPATおよびOATは引き続き稼働します。組織は、それぞれのペースでワークフローをOIDC接続に移行できます。
  • イメージ、レジストリ、ビルドワークフローに変更はありません。OIDC接続は認証手順のみを置き換えるものであり、それ以降の処理はすべて同じです。
  • ローカル開発環境やGitHub以外のCI環境では、依然としてPATとOATが使用されています。OIDC接続は、特にGitHub Actionsの代替として推奨されています。他のCIプロバイダーも需要に応じて追随するだろう。

詳しく見る

製品

関連記事