CI/CD の普及により、多くの開発チームが GitHub Actions を利用してコンテナー イメージのビルドや配布を自動化しています。
一方で、Docker Hub へのアクセスに利用する認証情報の管理は、運用上の課題となることがあります。従来は Personal Access Token (PAT) や Organization Access Token (OAT) を GitHub Secrets に登録して利用する方法が一般的でしたが、これらは長期間有効な認証情報であるため、適切な管理や定期的なローテーションが求められます。
Docker は GitHub Actions 向けの OIDC (OpenID Connect) 認証をサポートし、Docker Hub との認証をより安全かつシンプルに行えるようになりました。
本記事では、Docker OIDC Connections の概要と設定方法、導入によるメリットについてご紹介します。
OIDC 認証とは
OIDC (OpenID Connect) は、アプリケーションやサービス間で安全に認証を行うための標準規格です。
GitHub Actions では、ワークフロー実行時に OIDC トークンを発行できます。このトークンを利用することで、認証情報を事前に保存することなく外部サービスへアクセスできます。
Docker Hub の OIDC Connections では、
- GitHub Actions が OIDC トークンを取得
- Docker Hub にトークンを提示
- Docker が GitHub の署名を検証
- 条件に一致した場合のみ短時間有効なアクセス トークンを発行
- Docker Hub へアクセス
という流れで認証が行われます。
これにより、GitHub Secrets に長期的な Docker Hub の認証情報を保存する必要がなくなります。
従来の PAT 認証との違い
従来の方式では、Docker Hub 用の PAT を発行し、GitHub Secrets に保存して利用するのが一般的でした。
PAT 認証
- GitHub Secrets に認証情報を保存
- 定期的なローテーションが必要
- 漏洩時は無効化するまで利用可能
- 認証情報の管理が必要
OIDC 認証
- GitHub Secrets 不要
- 実行時に一時的なトークンを利用
- 短時間で失効
- 認証情報の管理負荷を軽減
特に組織内で複数のリポジトリやワークフローを運用している場合、管理対象となる認証情報を減らせる点は大きなメリットといえます。
Docker OIDC Connections の設定方法
それでは実際に設定してみましょう。
Step 1. Docker Hub 側で OIDC Connection を作成
Docker Home にログインし、対象 Organization を選択します。
その後、OIDC Connections → Create OIDC Connection を選択します。
OIDC Connection では、GitHub リポジトリやブランチなどの条件に基づいて、どの Docker Hub リソースへのアクセスを許可するかを設定します。また、1 つの Connection に対して最大 5 つの Ruleset を作成できます。
例えば以下のような条件を設定できます。
- 特定リポジトリの main ブランチのみ許可
repo:my-org/my-repo:ref:refs/heads/main
- release ブランチのみ許可
repo:my-org/my-repo:ref:refs/heads/release-*
- 対象リポジトリ全体を許可
repo:my-org/my-repo:*
設定完了後に表示される Connection ID を控えておきます。
Step 2. GitHub Actions Workflow を更新
続いて GitHub Actions 側を設定します。
以下のサンプルでは、<YOUR_CONNECTION_ID> を Step 1 で取得した Connection ID に、<YOUR_ORG_NAME> を Docker Organization 名に置き換えてください。
Workflow に以下を追加します。
permissions:
contents: read
id-token: write
steps:
- name: Docker login
uses: docker/login-action@v4
with:
username: <YOUR_ORG_NAME>
env:
DOCKERHUB_OIDC_CONNECTIONID: <YOUR_CONNECTION_ID>
ここで重要なのが
id-token: write
です。
この権限を付与することで GitHub Actions が OIDC トークンを取得できるようになります。また、docker/login-action は DOCKERHUB_OIDC_CONNECTIONID が設定されている場合、OIDC トークンの取得から Docker Hub へのログインまでを自動的に実行します。
Step 3. 動作確認
Workflow を実行し、
- Docker イメージのビルド
- Docker Hub への Push
- Docker Hub からの Pull
が正常に動作することを確認します。
認証に失敗した場合は、OIDC Connection の Failures タブから受信した claim 情報を確認できるため、設定内容の確認やトラブルシューティングに役立ちます。
Step 4. PAT を削除
OIDC で正常に動作することを確認できたら、GitHub Secrets に保存していた既存の PAT や OAT を削除します。これで Docker Hub 用の長期認証情報を管理する必要がなくなります。
OIDC 導入によるメリット
認証情報管理の負荷を軽減
PAT の発行や更新、ローテーションといった運用作業を減らせます。複数のリポジトリを運用している組織ほど、その効果は大きくなります。
セキュリティ向上
OIDC は実行時に発行される短時間有効のトークンを利用します。万が一トークンが漏洩しても、長期間利用されるリスクを抑えられます。
アクセス制御を細かく設定可能
リポジトリやブランチ単位でアクセス条件を定義できるため、最小権限の考え方に沿った運用を実現できます。
監査対応にも有効
長期認証情報を減らすことは、セキュリティ監査や内部統制の観点からもメリットがあります。
開発環境全体のガバナンスも重要に
Docker Hub の OIDC 認証は、GitHub Actions と Docker Hub 間の認証情報管理を改善するための機能です。長期的なアクセス トークンへの依存を減らし、CI/CD 環境のセキュリティと運用性を向上させることができます。
一方で、近年の開発環境では認証情報管理だけでなく、AI を活用した開発プロセス全体の統制も新たな課題となりつつあります。
GitHub Copilot や Claude Code、Cursor などの AI コーディング ツールの普及により、AI エージェントがコード生成やツール実行、外部サービスとの連携を行うケースが増えています。その結果、組織としては「どのツールへのアクセスを許可するのか」「どのような操作が行われたのか」を把握し、適切に管理する仕組みが求められるようになっています。
Docker では、こうした課題に対応するためのソリューションとして Docker AI Governance を提供しています。Docker AI Governance は、AI エージェントが利用できるツールやネットワーク アクセスの制御、ポリシー管理、監査ログの取得などを一元的に管理することを目的としたソリューションです。
OIDC 認証による認証情報管理の改善は、開発環境全体のガバナンス強化に向けた第一歩ともいえるでしょう。
まとめ
Docker Hub の GitHub Actions 向け OIDC 認証対応により、PAT を利用した従来の認証方式に代わる選択肢が提供されました。
設定作業は比較的シンプルでありながら、
- GitHub Secrets の削減
- 認証情報管理の効率化
- セキュリティ向上
- 最小権限運用の実現
といったメリットを期待できます。
GitHub Actions と Docker Hub を利用している組織であれば、一度 OIDC Connections の導入を検討してみてはいかがでしょうか。
また、AI を活用したソフトウェア開発が広がる中で、認証情報管理だけでなく、AI エージェントや開発環境全体のガバナンスも重要になっています。Docker AI Governance にご興味をお持ちの方や、Docker Sandboxes を含めた AI 活用基盤について詳しく知りたい方は、お気軽に Docker Preferred Reseller であるエクセルソフトまでお問い合わせください。
Docker の最新情報をお届けするエクセルソフトのメールニュース登録はこちら。
参照:
本記事に関する注意事項:
- 本記事は Docker 社が公開している情報を参考に、再構成、解説したものです。内容は執筆時点の情報に基づいており、製品の仕様や提供機能、画面構成は今後変更される可能性があります。最新情報については Docker の公式ドキュメントおよび製品ページをご確認ください。
- 本記事に記載されている会社名、製品名、サービス名等は、各社の商標または登録商標です。

