Notary Project

Notary Project は X.509 PKI で OCI アーティファクトに署名・検証し、各署名を対象アーティファクトの隣にレジストリ内へ保存する。

カテゴリ: Supply Chain
CNCF 成熟度: Incubating
言語: Go
ライセンス: Apache-2.0
リポジトリ: notaryproject/notation
ドキュメント基準コミット: 51ff5ec (2026-03-26)

何をするものか

Notary Project は OCI アーティファクトの署名・検証のための仕様群とツール群だ。旗艦実装は notation CLI で、コンテナイメージなどの OCI アーティファクトに署名し、設定済みの trust store と trust policy に照らして署名を検証する。署名・検証の中核ロジックは依存ライブラリ notation-go / notation-core-go 側にあり、notation はその上のコマンド層だ。

信頼モデルは標準 X.509 PKI に基づく。署名者は鍵と証明書チェーンを持ち、検証者は信頼するルート証明書と、どの ID がどのアーティファクトに署名できるかを定める trust policy を設定する。KMS や HSM にある外部鍵は CLI に組み込むのではなくプラグイン経由で扱う。

決定的な設計判断は、署名を同一リポジトリ内の対象アーティファクトに紐づく OCI Referrer として保存する点だ (cmd/notation/registry.go:59-93)。アーティファクトをレジストリ間でコピーしても署名が追随するため、前身の Docker Content Trust が抱えていたレジストリ間ポータビリティの欠如を解消する。

いつ使うか

すでに CA や PKI を運用していて、透明性ログではなく既存の X.509 信頼を土台にしたアーティファクト署名が欲しい。
イメージをレジストリ間でコピーしても残る署名が必要 (署名は OCI Referrer としてアーティファクトと同居する)。
KMS や HSM の鍵で署名し、署名プラグイン経由で統合したい。
Docker Content Trust から移行する。Azure Container Registry などが DCT を廃止し、Notary Project 署名を代替として案内している。

向かないのは、短命な ID と公開透明性ログによるキーレス署名が欲しい場合だ。そこは Sigstore/cosign が対象とするモデルになる。

このディープダイブの構成

歴史: 起源・マイルストーン・存在理由。
アーキテクチャ: コンポーネントとリクエストの流れ。
採用事例・エコシステム: 誰が動かし、周囲に何があるか。
内部実装: ソースから読んだ重要なコードパス。
はじめに: インストールと最初の動く構成。

Notary Project ​

何をするものか ​

いつ使うか ​

このディープダイブの構成 ​

出典 ​

Notary Project

何をするものか

いつ使うか

このディープダイブの構成

出典