Azure Container Registry（ACR）でDocker Content Trust（DCT）を使っている場合、今すぐ確認すべき結論は明確です。DCTは2028年3月31日にAzure Container Registryから完全削除される予定で、Azure CLIでもaz acr config content-trust関連コマンドの廃止対応が進み始めています。特に、--status enabledでDCTを有効化する運用、az acr check-healthでNotaryクライアント確認まで済んだとみなす運用、CI/CDでDOCKER_CONTENT_TRUST=1を前提にしている環境は、期限を待たずに見直しが必要です。(aka.ms)
今回の変更は「ACRが使えなくなる」という話ではありません。影響を受けるのは、ACR上でDocker Content Trustを使ってコンテナイメージの署名・検証をしている構成です。今後はDCTを継続利用するのではなく、Notary Project／Notationを使った署名・検証に段階的に移行するのが基本方針になります。(aka.ms)
Microsoft Azureの変更点：ACRのDocker Content Trust廃止がAzure CLIに反映
2026年5月20日にマージされたAzure CLIの公式PRでは、ACRのDocker Content Trust廃止に向けて、az acr config content-trust関連コマンドとaz acr check-healthの挙動変更が整理されています。対象コマンドは、az acr check-health、az acr config content-trust、az acr config content-trust show、az acr config content-trust updateです。(GitHub)
主な変更点は次のとおりです。
| 対象 | 変更内容 | 実務上の影響 |
|---|---|---|
az acr config content-trust | コマンドグループに廃止ラベル・廃止通知が追加 | 今後の新規導入や長期運用の前提にすべきではない |
az acr config content-trust show | コマンドグループの廃止に伴い非推奨扱い | 現状確認には使えるが、将来的な削除に備える必要がある |
az acr config content-trust update | --status enabledを受け付けない方向へ変更 | DCTを新たに有効化するスクリプトやCIが失敗する可能性がある |
az acr config content-trust update --status disabled | 実行時に警告表示と確認を求める変更 | 非対話のCI/CDでは確認プロンプトへの対応が必要 |
az acr check-health | Notaryクライアントのチェックを削除 | このコマンドだけではDCT／Notary関連の健全性確認にならない |
Azure CLIドキュメントでも、az acr config content-trustはDeprecatedと表示され、DCTは2028年3月31日に完全削除されると案内されています。また、az acr config content-trust updateについては、2026年6月予定のAzure CLI 2.87.0のBreaking Changeリリースで--status enabledがエラーになる旨が記載されています。リリース時期は変更される可能性があるため、実運用ではAzure CLI更新時にaz acr config content-trust update --helpで最新の挙動を確認してください。(Microsoft Learn)
重要な期限：2026年5月末から新規有効化が制限される
Docker Content Trust廃止は、2028年の完全削除だけを見ていると対応が遅れます。実務では、2026年5月31日と2026年6月予定のAzure CLI変更が近いチェックポイントになります。
| 時期 | 内容 | 確認すべきこと |
|---|---|---|
| 2025年3月31日 | DCTの非推奨化が開始 | DCTを前提にした新規設計を止める |
| 2026年5月20日 | Azure CLIのPRで廃止対応がマージ | 関連コマンドを使うスクリプトを洗い出す |
| 2026年5月31日 | 新規レジストリ、または過去にDCTを有効化していないレジストリではDCTを有効化できなくなる | 新規ACR作成時にDCT有効化を前提にしない |
| 2026年6月予定 | Azure CLI 2.87.0で--status enabledが受け付けられなくなる予定 | CI/CD、IaC、運用手順書から有効化コマンドを削除する |
| 2028年3月31日 | ACRからDCTが完全削除予定 | Notary Project／Notationへの移行を完了しておく |
特に注意したいのは、2026年5月31日以降、新しいACRや過去にDCTを有効化していないACRではDCTを有効化できなくなる点です。既存環境でDCTを使えている場合でも、新規環境・検証環境・DR環境を作ると同じ構成を再現できない可能性があります。(Microsoft Learn)
影響を受ける環境
今回の変更で影響を受けるのは、単にACRを使っている環境ではありません。影響が大きいのは、イメージ署名や署名済みイメージの検証をDCTに依存している環境です。
影響が大きいケース
次のいずれかに当てはまる場合は、早めに確認してください。
| 確認対象 | 影響 |
|---|---|
az acr config content-trust update -r <registry> --status enabledを使っている | Azure CLI更新後にコマンドが失敗する可能性がある |
CI/CDでDOCKER_CONTENT_TRUST=1を設定している | Docker push／pullの挙動がDCTに依存している |
docker trustやNotary CLIを使っている | DCT廃止後の署名・検証フローとして維持できない |
az acr check-healthをNotary確認として使っている | Notaryクライアント確認が行われなくなる |
| ACRのContent Trust設定を有効にしている | 将来の完全削除に向けて移行計画が必要 |
AcrImageSignerロールをDCT署名用に付与している | 移行後に不要権限として残る可能性がある |
| AKSや本番デプロイ前の承認で「署名済みイメージ」を条件にしている | NotationやRatifyなど別方式で検証ゲートを再設計する必要がある |
DCTは、署名済みタグのpushや、DCTを有効化したクライアントによる署名済みイメージのpullに使われます。DCTを有効化したクライアントは署名されていないタグをpullできないため、本番デプロイや配布制御にDCTを使っている場合、単にDCTを無効化するとセキュリティ要件を満たせなくなる可能性があります。(Microsoft Learn)
まず確認すべき設定とコマンド
管理者は、最初に「どのACRでDCTが有効なのか」「どのスクリプトがDCTを前提にしているのか」を分けて確認します。ACRの設定だけを見ても、CI/CDや開発端末側のDOCKER_CONTENT_TRUST設定を見落とすと、移行後にpushやpullが失敗します。
ACR側のContent Trust設定を確認する
az acr list --query "[].{name:name, resourceGroup:resourceGroup, sku:sku.name, loginServer:loginServer}" -o table対象レジストリが分かったら、Content Trustの状態を確認します。
az acr config content-trust show -r <registry-name> -g <resource-group>az acr config content-trust show自体も非推奨扱いになっていますが、現時点の棚卸しには役立ちます。ただし、将来的にこのコマンドグループは削除される可能性があるため、監視や恒久的な自動化に組み込むのは避けた方が安全です。(Microsoft Learn)
リポジトリやCI/CD定義からDCT依存を探す
LinuxやmacOSでは、リポジトリ直下で次のように検索します。
grep -R "az acr config content-trust" .
grep -R "DOCKER_CONTENT_TRUST" .
grep -R "docker trust\|notary" .PowerShellでは次のように確認できます。
Get-ChildItem -Recurse -File | Select-String -Pattern "az acr config content-trust","DOCKER_CONTENT_TRUST","docker trust","notary"検索で見つかった箇所は、次のように分類すると対応しやすくなります。
| 見つかった記述 | 判断 |
|---|---|
--status enabled | 削除または移行対象。今後は有効化に使えない |
--status disabled | 無効化手順として残す場合は、確認プロンプトや非対話実行を確認 |
DOCKER_CONTENT_TRUST=1 | DCT検証を前提にしているため、Notation検証へ置き換えを検討 |
docker trust sign | Notationによる再署名フローへ移行 |
notary versionやNotary CLI確認 | DCT向けの確認なので、Notation CLIやプラグイン確認へ置き換え |
az acr check-healthの結果確認 | Notaryチェックが含まれなくなるため、検証項目を分離 |
az acr check-health変更の注意点
az acr check-healthは、Dockerデーモン、Docker pull、Azure CLI、DNS、ACRエンドポイント、トークン取得など、ACR利用環境の健全性確認に使われるコマンドです。今回の変更では、Docker Content Trust廃止に伴い、Notaryクライアントのバージョン検証がこのコマンドから削除されます。(Microsoft Learn)
そのため、次のような運用は見直しが必要です。
az acr check-health -n myregistry -yこのコマンドが成功しても、今後は「Notaryクライアントが使える」「DCT署名の検証環境が整っている」とは判断できません。ACRの接続性確認と、署名・検証の確認は別のチェックとして分けてください。
移行後は、たとえば次のような確認に切り替えます。
notation version
notation plugin ls
notation verify <registry>.azurecr.io/<repo>@<digest>Notationを使う場合は、CLI本体だけでなく、Azure Key Vaultプラグイン、証明書、信頼ポリシー、検証対象のダイジェストまで含めて確認する必要があります。Microsoftの移行ガイドでも、Notation CLI、Key Vaultプラグイン、署名、検証、CI/CD連携が移行先の主要要素として示されています。(Microsoft Learn)
移行先はNotary Project／Notationが基本
Microsoftは、DCTの代替としてNotary Projectベースの署名・検証ソリューションを案内しています。Notary Projectは、コンテナイメージやOCI artifactsの真正性・完全性を扱うための仕様とツール群で、Notationはその仕様を実装するCLIとライブラリです。ACRでは、Notationの署名をOCI準拠レジストリに保存し、Azure Key Vaultで署名キーや証明書を管理できます。(aka.ms)
DCTとNotationの考え方は似ていますが、同じものではありません。
| 比較項目 | Docker Content Trust | Notary Project／Notation |
|---|---|---|
| 主な用途 | Dockerイメージの署名・検証 | コンテナイメージやOCI artifactsの署名・検証 |
| Azureでの位置づけ | 廃止予定 | 移行先として案内されている |
| 鍵管理 | Docker／Notary v1の運用に依存 | Azure Key Vaultとの連携が可能 |
| CI/CD連携 | 既存DCTフローに依存 | Azure DevOpsやGitHub Actionsでの署名・検証ガイドがある |
| AKSでの検証 | DCT単体では今後の継続利用に不向き | RatifyやAzure Policyなどで検証ゲートを構成できる |
| 将来性 | 2028年3月31日に削除予定 | OCI標準に沿った署名運用へ移行しやすい |
ここで重要なのは、DCTの設定を無効化することと、署名検証の移行を完了することは同じではないという点です。DCTを無効化しただけでは、これまでDCTで担保していた「誰が発行したイメージか」「改ざんされていないか」を別の仕組みで確認できるようにはなりません。
実務で進める移行手順
移行は、DCTを一気に無効化するのではなく、署名・検証の代替手段を先に動かしてから切り替えるのが安全です。特に本番AKS、外部配布用イメージ、セキュリティ審査がある環境では、無効化を先行させないでください。
| 手順 | 作業 | 成果物 |
|---|---|---|
| 1 | DCTを使っているACR、リポジトリ、CI/CD、開発端末を棚卸し | 影響範囲一覧 |
| 2 | DCTが担っている役割を整理 | 署名、pull制御、監査、デプロイゲートのどれかを明確化 |
| 3 | --status enabledを使う新規有効化処理を停止 | Azure CLI更新後の失敗を防ぐ |
| 4 | NotationとAzure Key Vaultによる署名方式を設計 | 鍵管理、証明書、RBAC、信頼ポリシー |
| 5 | CI/CDでイメージをダイジェスト指定で署名 | タグ上書きによる誤検証を防ぐ |
| 6 | デプロイ前にNotationで検証 | 未署名・改ざんイメージを検出 |
| 7 | AKSなど実行環境側の検証ゲートを整備 | RatifyやAzure Policyなどで運用 |
| 8 | DCTを無効化し、DCT用権限や手順書を整理 | 旧方式への依存を削除 |
MicrosoftのNotation手順でも、タグは上書き可能なため、署名対象の識別にはダイジェストを使うことが推奨されています。CI/CDでmyimage:latestのようなタグだけを署名・検証対象にすると、後からタグが別イメージを指す可能性があるため、本番運用では<registry>/<repo>@sha256:...形式を使うのが安全です。(Microsoft Learn)
移行後のCI/CD例
DCT時代の典型的な流れは、次のような形です。
export DOCKER_CONTENT_TRUST=1
az acr config content-trust update -r myregistry --status enabled
docker push myregistry.azurecr.io/app:v1今後は、DCTを有効化するのではなく、ビルド後にダイジェストを取得し、Notationで署名・検証する流れに置き換えます。
az acr login --name myregistry
DIGEST=$(az acr build \
-r myregistry \
-t myregistry.azurecr.io/app:v1 \
. \
--no-logs \
--query "outputImages[0].digest" \
-o tsv)
IMAGE=myregistry.azurecr.io/app@$DIGEST
notation sign \
--signature-format cose \
--id "$KEY_ID" \
--plugin azure-kv \
"$IMAGE"
notation verify "$IMAGE"これはあくまで構成例です。実運用では、Key Vaultの証明書、notation-azure-kvプラグイン、署名に使うID、検証用のtrust policy、CI/CDの認証方式を環境に合わせて設計してください。Microsoftの手順では、Notation CLIとKey Vaultプラグインの導入、Key Vault証明書の作成、イメージ署名、信頼ポリシー作成、notation verifyによる検証までが説明されています。(Microsoft Learn)
DCTを無効化するときの注意点
DCTを無効化する場合は、次のコマンドを使います。
az acr config content-trust update -r myregistry --status disabledただし、PRでは--status disabled実行時に警告を表示し、確認を求める変更が入っています。手動実行では問題になりにくい一方、CI/CDや運用自動化では確認プロンプトでジョブが停止する可能性があります。Azure CLIの該当バージョンに更新した後、非対話実行で使う場合は--helpで--yesなどの確認スキップ方法を確認してから反映してください。(GitHub)
また、DCTの無効化は「署名データを後から簡単に戻せる作業」ではありません。Microsoft Learnでは、DCTの無効化・再有効化により、レジストリ内の全リポジトリの署名データが削除され、復元できないこと、ただしイメージ自体は削除されないことが説明されています。監査や証跡としてDCT署名情報が必要な場合は、無効化前に必要な記録を残してください。(Microsoft Learn)
管理者と開発者が分担して確認すべきこと
DCT廃止対応は、Azure管理者だけで完結しません。ACR設定、IAM、CI/CD、Dockerクライアント、AKSデプロイ、監査要件がまたがるため、担当ごとに確認ポイントを分けると進めやすくなります。
| 担当 | 確認ポイント | 具体的な作業 |
|---|---|---|
| Azure管理者 | ACRのContent Trust設定 | DCT有効レジストリを棚卸しし、移行計画を作る |
| IAM管理者 | DCT用ロールとKey Vault権限 | AcrImageSigner、AcrPush、Key Vault Crypto Userなどを整理 |
| 開発者 | Dockerクライアント設定 | DOCKER_CONTENT_TRUSTやdocker trust利用箇所を削除・置換 |
| CI/CD担当 | ビルド後の署名 | タグではなくダイジェストを使ってNotation署名する |
| セキュリティ担当 | 検証ポリシー | trust policy、証明書、署名者の信頼条件を定義 |
| Kubernetes担当 | デプロイ時検証 | AKSでRatifyやAzure Policyを使うか検討 |
| 運用担当 | 監視と手順書 | az acr check-healthの解釈を更新し、Notary確認を別手順化 |
DCTでは署名権限としてAcrImageSignerが使われますが、NotationとAzure Key Vaultを使う構成では、ACRへのpush／pull権限に加えて、Key Vaultの証明書・暗号操作に関する権限設計が必要になります。移行後にDCT用ロールが残ると不要権限になるため、移行完了後に権限棚卸しを行うのがおすすめです。(Microsoft Learn)
失敗しやすいポイント
DCTを無効化しただけで移行完了と考える
最も危険なのは、az acr config content-trust update --status disabledを実行して終わりにすることです。DCTを無効化すると、DCTによる署名・検証の制御はなくなります。これまで本番デプロイの安全性をDCTに依存していた場合、Notationによる署名と検証、AKS側のポリシー適用などを先に用意してください。
az acr check-healthの成功を署名検証の成功と誤解する
今後のaz acr check-healthは、Notaryクライアントのバージョン確認を行いません。ACR接続確認としては有用ですが、DCTやNotationの検証環境が整っている証明にはなりません。署名検証はnotation verifyなど、専用の確認手順に分ける必要があります。(Microsoft Learn)
latestタグを署名対象の中心にする
latestやstableなどのタグは便利ですが、タグは後から別のイメージを指す可能性があります。署名・検証の確実性を高めるには、CI/CDでビルド後のダイジェストを取得し、そのダイジェストを対象に署名してください。MicrosoftのNotation手順でも、タグは可変で上書き可能なため、署名対象の識別にはダイジェストを使うことが示されています。(Microsoft Learn)
新規環境でDCTを再現できると思い込む
2026年5月31日以降、新しいACRや過去にDCTを有効化していないACRではDCTを有効化できなくなります。既存本番環境ではDCTが動いていても、新規の検証環境、災害対策環境、サブスクリプション移行後の環境で同じ手順が通らない可能性があります。(Microsoft Learn)
Azure CLIを固定して先送りする
一時的にAzure CLIのバージョンを固定すれば、既存スクリプトの失敗を遅らせられる場合があります。しかし、DCT自体の削除予定は変わりません。CLI固定は移行期間中の暫定策にとどめ、--status enabledを使う処理は早めに削除してください。
期限前に取るべき次の行動
まず、すべてのACRでContent Trustの状態を確認し、CI/CD定義からaz acr config content-trust、DOCKER_CONTENT_TRUST、docker trust、notaryを検索してください。見つかった箇所は、DCTを単に無効化する箇所と、Notationによる署名・検証へ置き換える箇所に分けます。
本番環境では、次の順序で進めるのが安全です。
| 優先度 | やること |
|---|---|
| 高 | --status enabledを使う自動化を削除・停止する |
| 高 | DCT有効ACRとDCT依存CI/CDを棚卸しする |
| 高 | NotationとKey Vaultによる署名方式を検証環境で試す |
| 中 | az acr check-healthの結果確認ルールを更新する |
| 中 | AKSやデプロイ前検証でnotation verify、Ratify、Azure Policyの適用を検討する |
| 中 | DCT用のAcrImageSignerロールを移行後に見直す |
| 低 | 手順書、監査資料、開発者向けガイドを更新する |
Docker Content Trustの廃止対応で重要なのは、期限直前にDCTを止めることではありません。DCTが担っていた署名・検証・デプロイ制御を洗い出し、Notationを中心とした新しいサプライチェーンセキュリティの仕組みに置き換えることです。まずはDCT依存箇所の検索と、--status enabledを使う処理の削除から着手してください。
コメント