Docker Content Trust完全ガイド｜イメージの署名と検証でサプライチェーンを守る

プライベートレジストリ（7-3）を立てても、イメージが途中で改ざんされていないかは保証されません。悪意ある中間者・侵害されたビルドマシン・タグの乗っ取り——これらのリスクに対処するのがイメージ署名です。Docker 公式の仕組み Docker Content Trust（DCT） と、新しい業界標準 Cosign / Sigstore の両方を押さえます。

💡 この記事のゴール
① 「署名」が何を保証するかを理解
② Docker Content Trust の基本操作（DOCKER_CONTENT_TRUST=1）
③ 鍵の種類と管理
④ 注意点：DCT の位置づけと Cosign への移行潮流

1. 脅威モデル：何から守る？

脅威	攻撃例	署名で防げる？
イメージの改ざん	中間者がレジストリ配信中にバイナリをすり替え	✅ 検知可能
タグのすり替え	攻撃者が `myapp:1.0.0` に悪性イメージを上書きpush	✅ 検知可能
なりすまし push	攻撃者が正当アカウントを装って push	✅ 署名鍵がなければpush不可
ベースイメージの脆弱性	古いOpenSSLなどを含んだまま	❌（これは脆弱性スキャン 8-6）
実行時の攻撃	コンテナエスケープなど	❌（これは rootless/seccomp 8章）

💡 署名は「同一性の証明」
署名の仕事は「開発者が push したものと、ユーザーが pull するものが同じであること」を保証する。中身の安全性は別の仕組み（脆弱性スキャン・ポリシー）で担保します。

2. Docker Content Trust とは

Docker 公式の署名機構。環境変数 DOCKER_CONTENT_TRUST=1 を設定するだけで：

docker push 時に自動で署名
docker pull 時に自動で検証
署名がない／壊れているイメージは pull 拒否

背後では Notary（ノータリー）というサーバが署名情報を管理します。The Update Framework (TUF) をベースにしたセキュアな配布システムです。

3. 基本操作

3-1. 有効化

# シェルで有効化
export DOCKER_CONTENT_TRUST=1

# または個別コマンドで
DOCKER_CONTENT_TRUST=1 docker push myid/myapp:1.0

3-2. push（初回は鍵が自動生成）

$ DOCKER_CONTENT_TRUST=1 docker push myid/myapp:1.0
Signing and pushing trust metadata
You are about to create a new root signing key passphrase.
Enter passphrase for new root key with ID xxxx:   （ルート鍵のパス）
Enter passphrase for new repository key:         （リポジトリ鍵のパス）
Successfully signed docker.io/myid/myapp:1.0

3-3. pull 時の検証

# 正常なイメージ：pull 成功
$ DOCKER_CONTENT_TRUST=1 docker pull myid/myapp:1.0
Pull (1 of 1): myid/myapp:1.0@sha256:abc...
...

# 署名されていないイメージ：pull 拒否
$ DOCKER_CONTENT_TRUST=1 docker pull unsigned-image:latest
Error: remote trust data does not exist for docker.io/unsigned-image: ...

3-4. 署名情報の確認

$ docker trust inspect --pretty myid/myapp
Signatures for myid/myapp

SIGNED TAG   DIGEST                  SIGNERS
1.0          abc123def456...         user1@example.com

Administrative keys for myid/myapp
Repository Key: xxxxxxx...
Root Key:       yyyyyyy...

4. 鍵の種類と管理

鍵	用途	重要度
Root Key	最上位信頼の源。リポジトリ鍵の作成に使う	最高（紛失したらやり直せない）
Repository Key	リポジトリ単位の署名	高
Targets Key	個別タグの署名	中
Timestamp Key	サーバ側管理・リプレイ攻撃防止	サーバ管理

鍵は ~/.docker/trust/ に保存されます。Root Key は必ずオフラインバックアップすること（USBメモリ・金庫）。失うと同名リポジトリで再び署名できなくなります。

⚠️ パスフレーズを忘れないこと
鍵自体がバックアップされていても、パスフレーズがなければ使えません。チーム運用ではパスワードマネージャで共有するか、HSM/KMS に鍵を格納するのが安全策です。

5. DCT の制約と現状

制約	内容
対応レジストリが限られる	Docker Hub と一部のみ。ECR/GAR/GHCR は非対応
Notary 運用が必要	自前レジストリで使うには Notary サーバも立てる必要
鍵管理が煩雑	Root 鍵紛失の事故が多い
エコシステムが縮小	Notary v1 は積極開発停止、Notary v2 は別物
Kubernetes 連携が弱い	OCI 署名の標準ではない

⚠️ DCTはレガシー化しつつある
Docker Content Trust は 2016 年頃の古い仕組みで、現在では「まだ動くけど将来的には Cosign に置き換えていく」という潮流です。新規案件では次セクションの Cosign / Sigstore を検討するのが標準です。

6. 新標準：Cosign / Sigstore

Sigstore プロジェクトが提供する Cosign は、2021 年以降の業界標準になりつつあるイメージ署名ツール。鍵レス運用（短期証明書）や SBOM 連携、OCI レジストリ直書き込みなど、DCT の弱点を解消した設計です。

観点	DCT（Notary v1）	Cosign（Sigstore）
対応レジストリ	Hub など限定	OCI 準拠なら全て（ECR・GAR・GHCR・Harbor…）
鍵運用	自前生成・長期保持	鍵レス（OIDC）も選択可
連携	Notary サーバ必要	直接 OCI レジストリに signature tag で保存
K8s / GitHub Actions	連携弱	サポート豊富
開発状況	停滞	活発・CNCF卒業

Cosign の最小例

# インストール（macOS）
brew install cosign

# 鍵ペア生成
cosign generate-key-pair

# 署名（push 後のイメージに対して）
cosign sign --key cosign.key myid/myapp:1.0

# 検証
cosign verify --key cosign.pub myid/myapp:1.0

💡 Keyless 署名（OIDC）
cosign sign myid/myapp:1.0（鍵指定なし）で、GitHub/Google などの OIDC 認証を使って短期証明書ベースで署名できます。鍵の長期保管リスクがないのが最大の利点。CI/CD パイプラインとの相性が抜群です。

7. まとめ

押さえどころ	内容
署名の仕事	配信中・保管中の改ざん検知（中身の安全性は別軸）
DCT 最小例	`DOCKER_CONTENT_TRUST=1 docker push/pull`
鍵管理	Root Key は必ずオフラインバックアップ＋パスフレーズ管理
DCTの弱点	対応レジストリ限定・K8s 連携弱・開発停滞
新標準	Cosign（Sigstore）への移行が潮流
組み合わせ	署名 + 脆弱性スキャン（8-6）で初めてサプライチェーン防御