要約: Docker Content Trust (DCT) と notary.docker.io の Notary v 1サービスは完全に廃止されます (最初に発表されたのは 2025の7月)このブログでは、何が変化しているのか、誰が影響を受けるのか、そして現代的な代替手段に移行する方法について解説します。
10年前、Docker Content Trust（DCT）は、Update FrameworkとNotary v 1プロジェクトに基づいて構築され、コンテナエコシステムにイメージの整合性と発行者を検証する最初の方法の1つを提供しました。上流の Notary v 1コードベースはもはやメンテナンスされておらず、よりモダンな署名ツールが標準となり、今日ではごく少数 ( 0 . 05 %) の Docker Hub プルが DCT に依存しています。
昨年、Docker公式イメージ向けのDCTの廃止を開始しましたが、今回、DCTとnotary.docker.ioのNotary v 1サービスを完全に廃止することで、その作業を完了します。この記事では、何が変わるのか、誰が影響を受けるのか（ほとんどの人にとっては何も影響はない）、そしてユーザーが利用できる現代的な代替手段について解説します。
Docker Content Trust（DCT）を廃止する理由は何ですか？
DCTは、アップストリームのNotary v 1サーバーに依存しており、これは2015で最初にリリースされたオリジナルのTUFベースの実装ですが、このプロジェクトはもはやメンテナンスされていません。それ以降、エコシステムはSigstore/CosignやNotary ProjectのNotationといったOCIネイティブの署名ツールに標準化され、準拠したレジストリであればどこでもイメージと共に署名を保存できるようになり、別途トラストインフラストラクチャを運用する必要がなくなった。より広範なエコシステムではこのアプローチが廃止されつつあります。Microsoft はしばらく前に Azure Container Registry での DCT サポートを非推奨にし、Harbor も Notary v 1サポートを非推奨にしました。
Notary v 1を廃止することで、開発者が既に採用している他の最新の標準ベースのツール（下記参照）や、Docker Hub 上で安全なデフォルト設定を第一級の要素とするための取り組みに投資を集中させることができます。
この変更によって影響を受けるのは誰ですか？
DCTはオプトイン方式であり、通常のイメージプル（ docker pull ）ではNotaryサービスには影響しないため、意図的に有効にしたことがなければ、ワークフローに何も変更はありません。ここで読むのをやめても構いません。
この変更は、DCTを使用するように設定した場合に重要になります。通常、その変更はいくつかの方法で現れます。
- 環境、シェルプロファイル、CIパイプライン、またはDockerfileで
DOCKER_CONTENT_TRUST= 1が設定されています。 - スクリプトや自動化では
docker trust sign、docker trust inspect、またはdocker trust revoke使用します。 - Kubernetesのアドミッションコントローラーまたはデプロイメントポリシーは、DCT署名を確認します。
- DCT署名を有効にした状態でイメージをDocker Hubに公開します。
DOCKER_CONTENT_TRUST一度も設定したことがなく、 docker trustコマンドを使用していない場合は、この変更は影響しません。
退職への道筋：タイムライン
DCT（デュアルクラッチトランスミッション）は、一度にすべて廃止するのではなく、段階的に廃止していく予定です。停電は短時間で計画されたものであり、修理する時間があるうちに、まだ電力供給に依存しているパイプラインを洗浄するための予行演習です。書き込みは閲覧よりも先に行われるため、署名は検証前に完了し、出版社はいち早く情報を受け取ることができる。
|
日付 |
何が起こるのですか |
|
2026年7月14日 |
4時間書き込み停電 |
|
2026年7月15日 |
4時間書き込み停電 |
|
8月 10日、 2026 |
4時間読書停電 |
|
8月 12日、 2026 |
4時間読書停電 |
|
12月 8日、 2026 |
完全シャットダウン |
ウィンドウの有効時間は約4時間で、太平洋標準時午前8時に開始します。
これはDCTの信頼操作のみに影響することに注意してください。通常のdocker pullおよびdocker push操作は、これらの期間中も引き続き動作します。
影響を受けた場合の対処法：移行ガイドと代替案
上記のいずれかのケースがあなたのシステムに当てはまる場合は、DCTからスムーズに移行する方法を以下に示します。このエコシステムは、強力で広く採用されている少数のツールに落ち着いているため、これはマニュアルというよりはメニューに近いものです。手順は、最も迅速な問題解決から最も包括的な設定まで多岐にわたります。ご自身のワークフローに合った最先端のテクノロジーを選択し、状況に応じてリストの下位まで進んでください。
イメージの取得が確実に成功する
シャットダウン日以降もイメージの取得が確実に機能するようにすることが唯一の目的であれば、DCTを無効にしてください。これはワークフローの障害を解消する最速の方法ですが、タグレベルの検証ができなくなります。
# Remove from your current shell session
unset DOCKER_CONTENT_TRUST
# Or explicitly disable it
export DOCKER_CONTENT_TRUST=0
シェルプロファイル、CI/CD 構成、Compose ファイル、K 8 s マニフェストなど、この変数が設定されている可能性のある場所を環境内で検索します。DCTが無効になると、すべての牽引機能は正常に動作し続けます。
抽出が再現可能であることを保証する
画像レジストリ上のタグは、画像が更新されると変更される場合があります。ダイジェストによる取得は、タグが移動または上書きされたかどうかに関わらず、期待どおりの画像コンテンツを確実に取得できることを保証します。ダイジェストは変更不可能です。
# Find the digest of an image you have pulled
docker pull busybox:latest
docker images --digests busybox
# REPOSITORY TAG DIGEST IMAGE ID
# busybox latest sha256:f85340bf... abc123def456
# Pull by digest
docker pull busybox@sha256:f85340bf...
再現性のあるビルドのためには、Dockerfile でダイジェストを使用し、予測可能なデプロイメントを保証するために Kubernetes マニフェストまたは Compose ファイルでダイジェストを使用してください。
ダイジェスト版のピン留めはコンテンツの完全性（要求した内容が正確に提供される）を検証するものの、それ自体では発行者の身元を証明するものではありません。そのためには暗号署名が必要であり、そこでSigstore/CosignとNotationが登場する。
発行者の身元を証明する
ハブにおけるDCTの署名機能は、成熟し、積極的に維持管理されている2つの署名プロジェクトに置き換えられた。両方とも、OCI準拠のレジストリに画像とともに署名を保存します。
オプションA：Sigstore / Cosign
CosignはSigstoreプロジェクトの一部であり、OIDC IDに紐づけられた有効期限の短い証明書を使用したIDベースの署名をサポートします。署名は、イメージと同じレジストリにOCIアーティファクトとして保存されます。
- Sigstore クイックスタート: https://docs.sigstore.dev/quickstart/quickstart-cosign/
- GitHubでの共同署名： https://github.com/sigstore/cosign
オプションB：表記法
Notationは、Notary ProjectのCLI（コマンドラインインターフェース）です。これは証明書ベースのPKIモデルを使用し、署名をOCI参照アーティファクトとして保存します。
- 記法クイックスタート： https://notaryproject.dev/docs/quickstart/
- GitHub上の表記法： https://github.com/notaryproject/notation
本番環境での検証の強制
画像に署名することは、物語の半分に過ぎない。セキュリティ上のメリットを最大限に享受するには、署名付きイメージのみがデプロイされるように徹底する必要があります。
Kyverno（Cosignと提携）
Kyvernoは、クラスタに取り込む前にCosignの署名を検証できます。詳細はドキュメントを参照してください。
Ratify + Gatekeeper（表記法と連携）
Ratifyは、ポッドを受け入れる前にNotationの署名を検証できます。セットアップ手順については、 Ratifyのクイックスタートガイドを参照してください。
組み込みの代替手段としてDocker強化イメージを使用する
現在、Docker Hub のベースイメージの検証に DCT を利用している場合、Docker Hardened Images (DHI) に切り替えることは、無料で安全な解決策となります。すべてのDHIには、暗号署名、出所証明、およびSBOMが既に組み込まれています。
これは、DCTで頼りにしていた整合性チェックが保証されるだけでなく、さらに強化されることを意味します。DHIイメージは設計上最小限に抑えられており、新たなCVEが発生するたびに継続的に再構築されます。これは単に検証メカニズムを置き換えるだけでなく、最初からより安全なベースイメージを取得することになります。
- 詳細はこちらをご覧ください： https://docs.docker.com/dhi/
- または、 dhi.ioで無料カタログをご覧ください。
助けが必要?
引っ越しを計画する際に知っておくと良いことがいくつかあります。
現在DCTを使用してイメージに署名しているDocker Hubの発行者の場合、Dockerはお客様に代わって代替署名を提供することはできません。自分の画像に署名するには、CosignまたはNotationを採用する必要があります。
DCTで署名された第三者の画像の消費者である場合は、それらの出版社に直接連絡して、最新の署名方法を採用する予定があるかどうかを確認してください。
シャットダウンに関するご質問や問題、または移行計画について弊社と直接連携をご希望の場合は、Dockerサポートまでお問い合わせください。
