Docker社、イメージ検証機能「Docker Content Trust」を完全廃止へ 2026年12月の完全シャットダウンに向けた移行手順を公開
要点
- Docker社は、イメージの完全性と発行元を検証する「Docker Content Trust（DCT）」とNotary v1サービスを完全に廃止する。
- 廃止に向けて、2026年7月と8月に一時的な機能停止（ブラウンアウト）を行い、同年12月8日に完全シャットダウンを実施する。
- DCTは明示的に設定しなければ動作しないオプトイン機能であり、無効のまま利用している大半のユーザーには影響しない。
- 影響を受けるユーザーに向けて、ダイジェスト値によるイメージ指定や、モダンな代替ツール「Cosign」または「Notation」への移行を推奨している。
リード文
米Docker社は2026年6月16日、コンテナイメージの完全性や発行元の安全性を検証する機能「Docker Content Trust（以下、DCT）」と、その基盤である「notary.docker.io」上のNotary v1サービスを完全に廃止することを発表した。2025年7月に廃止方針が発表されていたが、今回、具体的な廃止に向けたスケジュールと影響を受けるユーザー向けの移行ガイダンスが公開された。
本文
廃止に至る背景
DCTは10年前、コンテナのエコシステムにおいてイメージの完全性を検証し、誰が発行したかを確かめる最初の手段として登場した。この機能は、ソフトウェア更新の安全性を確保するためのフレームワークである「TUF（The Update Framework：セキュリティ保護されたアップデートシステムの標準）」と、その初期の実装である「Notary v1」プロジェクトに基づいて構築されていた。
しかし現在、上流のNotary v1プロジェクトはメンテナンスされておらず、よりモダンな署名検証ツールが標準となっている。Docker社によると、現在Docker Hubで行われているイメージのプル（取得）処理全体のうち、DCTを利用しているケースはわずか0.05%未満にとどまっているという。
また、業界全体でもNotary v1からの移行が進んでいる。MicrosoftのAzure Container Registryでは以前からDCTサポートが非推奨となっており、レジストリ管理ソフトウェアのHarborでもバージョン2.9.0以降でNotary v1のサポートが非推奨化された。これらを受け、Docker社は古いNotary v1への投資を終了し、モダンな標準ツールや、Docker Hubのデフォルトのセキュリティ機能の強化に注力する意向を明らかにしている。
影響を受けるユーザー
DCTは明示的に有効化しなければ機能しないオプトイン方式の仕組みである。そのため、これまで意図的にDCTを設定していなかったユーザーは、通常のイメージ取得操作（docker pull）に影響はなく、特段の対応を行う必要はない。
一方で、以下のような利用状況に当てはまる開発者や管理者は、今回の廃止による影響を受けるため対応が必要となる。
- 環境変数やCI/CDパイプライン、Dockerfile内に
DOCKER_CONTENT_TRUST=1を設定している場合 - 運用スクリプトや自動化ツールで、
docker trust sign、docker trust inspect、docker trust revokeといったコマンドを使用している場合 - KubernetesのAdmission Controller（アドミッションコントローラー：APIリクエストを検証・制御する拡張機能）などでDCT署名を検証している場合
- Docker Hubへイメージを公開する際に、DCTによる署名を有効にしている場合
段階的廃止のタイムライン
Docker社は、影響を事前に検知できるよう、本番環境の動作を一時的に停止させる「ブラウンアウト」試験を段階的に実施する。不具合が発生した際に最も早く検知できるよう、情報の読み込みよりも、署名の書き込み操作のブラウンアウトが先に実施される。
具体的なスケジュールは以下の通りである（日付はいずれも2026年、時間は太平洋時間午前8時からそれぞれ約4時間）。
- 7月14日・15日：それぞれ4時間の書き込みブラウンアウト（署名作成などが一時不可）
- 8月10日・12日：それぞれ4時間の読み込みブラウンアウト（検証処理などが一時不可）
- 12月8日：サービスの完全終了（完全シャットダウン）
なお、これらのブラウンアウト期間中も、通常のイメージの取得（docker pull）や送信（docker push）自体は問題なく機能し続けると説明されている。
移行手順と推奨される代替案
影響を受けるユーザー向けに、Docker社はいくつかの移行ステップを提示している。
1. イメージ取得の継続（検証の無効化）
まずはイメージの取得を継続させるための最も迅速な方法は、DCT自体を無効化することだ。一時的に検証をスキップするには、シェルセッションで unset DOCKER_CONTENT_TRUST を実行するか、環境変数で export DOCKER_CONTENT_TRUST=0 を設定する。CI/CDやKubernetesマニフェストなどに設定がないか確認し、無効化することでイメージの取得が継続できる。ただし、この方法は整合性の検証は行われない。
2. プルの再現性担保（ダイジェストによる指定）
常に意図した通りのイメージ内容を取得するには、「ダイジェスト」（イメージ固有の暗号ハッシュ値）を用いた指定が推奨される。
ローカルで取得したイメージのダイジェストは、docker images --digests で確認できる。取得時は docker pull busybox@sha256:f85340bf... のように指定する。ダイジェスト値は不変であるため、安全なビルドやデプロイを担保できる。ただし、ダイジェスト値のみでは発行元の身元までは証明できないため、暗号署名ツールが代替手段として推奨される。
3. 発行元証明のための代替ツール
Docker Hubとも統合し、OCI（Open Container Initiative：コンテナの標準仕様を定める団体）準拠のレジストリで動作する成熟した署名プロジェクトとして、次の2つが紹介されている。
- Sigstore / Cosign：OIDC（OpenID Connect：ID連携のオープン標準規格）に基づき、短寿命の証明書を利用したアイデンティティベースの署名をサポートする。署名データはレジストリ内にOCIアーティファクトとして保存される。
- Notation：Notary Projectが開発するCLIツール。証明書を用いたPKI（公開鍵暗号基盤：公開鍵と所有者の関係を保証する仕組み）モデルを採用しており、署名をOCIリファレンスアーティファクトとして格納する。
4. 本番環境での署名検証
本番環境で署名検証を強制する仕組みとして、Cosign署名の検証に対応するポリシーエンジン「Kyverno」や、Notation署名の検証に対応する「Ratify」と「Gatekeeper」の組み合わせが紹介されている。