こちらも参考情報としての翻訳です。2015年8月にリリースされた、Docker 1.8 の新機能に関する補足となります。

Introducing Docker Content Trust | Docker Blog
http://blog.docker.com/2015/08/content-trust-docker-1-8/

オリジナルの投稿は、2015年8月12日に、Docker 社の Diogo Mónica 氏によって書かれました。画像は、同ブログからの引用です。

—-ここから—-

■ 更新フレームワーク(TUF) を使ったイメージに対する署名と検査

Docker コミュニティから寄せられた一般的なリクエストは、強力な暗号方式とインフラ上でソフトウェアを実行するコードのバージョンに関する保証でした。これは安全性やプロダクションにおける開発に対して絶対的に不可欠なものです。これらの要望に対する答えとして、私達は Docker Content Trust と呼ばれる Docker 1.8 の新機能を紹介できることを嬉しく思います。これには更新フレームワーク（TUF） の内部で Docker は Notary を使っており、Notary はあらゆるコンテント（訳者注；ここでは主に Docker イメージの内容物を指す言葉）に対する信頼を提供するオープンソースのツールです。

■ Docker Content Trust 入門

Docker Content Trust（ドッカー・コンテント・トラスト）は Docker Engine 1.8 の新機能であり、Docker イメージの提供者を検証することができます。提供者がリモートのレジストリにイメージを送信（プッシュ）する前に、Docker Engine はローカルで提供者の秘密鍵を使い、イメージに署名します。その後、このイメージを取得（プル）するとき、Docker Engine は提供者の公開鍵を使い、実行しようとしているイメージが本当に提供者が作成したものか確認します。もし改竄されている場合は、イメージを無効化します。

主に焦点をあてているのは、使いやすさを犠牲にすることなく、Docker に高いレベルのセキュリティをもたらすことです。Docker Content Trust を有効にしてしまえば、これまでの一般的な Docker ワークフローと密接につながっているので、追加のコマンドを覚える必要はありません。これまで通り利用者は「docker pull」「docker push」「docker biuld」「docker create」「docker run」コマンドを使うだけでも、常に署名されたイメージしか操作しないようにできます。

この Docker Content Trust は、利用者がオプト・イン機能として使えるものです（訳者注；使うかどうかは私達の設定次第）。Content Trust を有効にすると、全てのオペレータ（作業者）は強制的にリモート・レジストリを使うことになり、署名済みかつ検証済みのイメージしか利用できなくなります。この新機能は私達がコミュニティと共に開発してきたものであり、オプト・インを使い、私達にフィードバックをもたらしてくれることを心待ちにしています。

■ Docker Content Trust の概要

下図が示すのは、Docker Content Trust がどのように動作するかの概要です。イメージがレポジトリに送信（プッシュ）されると、そのイメージは提供者の秘密鍵を使って署名されます。利用者がイメージを始めて操作するとき、その提供者に対する信頼を確立するようにすると、以降、その同じ提供者からの全ての相互作業において、有効な署名による検証を必要とします。これは SSH が初回接続時に使う信頼方式と似ているものであり、開発者にとっては慣れ親しんでいるものです。とりわけ初回の信頼に関して HTTPS を使う公開 PKI に対応することで、セキュリティに対する利便性をもたらします。

■ Content Trust の主な構造

Docker Content Trust はオフライン鍵（Offline key）とタギング鍵（Tagging key）という２つの異なった鍵を持ちます。これらは提供者がイメージを送信（プッシュ）するときに生成され、クライアント側に保管されます。各々のレポジトリは、それぞれがユニークなタギング鍵を持っています。利用者が「docker pull」コマンドを初めて実行すると、オフライン鍵を使ってレポジトリとの信頼を確立します。

• タギング鍵（Tagging Key）は提供者による新しいレポジトリ毎に生成されます。これにより、対象のレポジトリに対する送信や共有をするには、あらゆる人やシステムが認証を必要とするようになります。
• オフライン鍵（Offline Key）は最も重要な鍵です。これは、自分のレポジトリに対する信頼の根本（root）となるものです。異なったレポジトリに対しても、同じオフライン鍵を使います。この鍵を使うのは、新しいレポジトリを作成するときか、既存の鍵を差し替える（rotate key）時のみです。オフライン鍵は常にオフラインを保つべきであり（訳者注；ネットワークには接続しないという意味）、つまりこれが、あらゆる攻撃に対抗する有利な点です。

信頼が確立されると、Docker Content Trust は TUF（訳者注：更新フレームワーク、The Update Framework）を使い、内容の品質保全と新しさを保障します。新しさを保障するためにタイムスタンプ鍵（Timestamp key）が生成され、リモート・サーバ上に保管されます。Docker がタイムスタンプ鍵を管理してくれるので、内容をクライアント側で定期的に再読込しなければいけなかった面倒さを減らしてくれます。

鍵は重要な要素であり、自分のレポジトリ内容の署名や、信頼の検証に使います。これらの鍵のバックアップを安全な場所に作成するのは、非常に重要です。大切なのは、タギング鍵やタイムスタンプ鍵をなくしても復旧可能ですが。一方でオフライン鍵の復旧はできません。詳細についてはバックアップ方法のドキュメント（英語）をお読みください。

■ イメージ偽造に対する防衛

１つでも信頼が確立されれば、Docker Content Trust はネットワーク上で悪意のある権限を持つ人に対して、つまり、介入者攻撃(man-in-the-middle attack)に対して抵抗できる能力を提供できることを保障します。これは悪意のある人物がレジストリで危険なイベントを起こそうとしても、イメージ内容に対する改竄やユーザに対する攻撃ができなくなることを意味します。このような状況になると、内容の正常性に対する確認がとれないため、利用者によるすべての docker コマンドの実行を拒否（hard fail）するメッセージが表示されます。

■ リプレイ攻撃に対する防衛

リプレイ攻撃（訳者注；データ転送を繰り返すことで、処理遅延を引き起こす攻撃）は、有効なデータ転送が繰り返されることにより、他のシステムに対する迷惑となるため、安全な分散システムの設計における一般的な課題です。同様の問題はソフトウェアの更新システムにも存在しており、古いバージョンのソフトウェアに対する署名が、最も新しい課題として表面化しています。これは悪意のある人物が利用者のホスト上で、既知のセキュリティ脆弱性による攻撃を行えることです。

Docker Content Trust は、イメージの公開時にタイムスタンプ鍵を使い、利用者が最も新しいイメージ内容しか扱えないように保障するので、これでリプレイ攻撃に対抗できるようにします。

■ 鍵の漏洩に対する防衛

以下の図はタギング鍵が危険になったシナリオを図式化したものです。タギング鍵はオンラインで使う性質のため、実際のところ、新しいイメージ内容をレポジトリに送信（プッシュ）する度に毎回鍵を使うため、オフライン鍵にくらべて本質的に晒されやすいものです。単一の鍵を使い、データの品質を保証しようとするシステムがあったとしても、鍵が漏洩した場合に修復する手立てはありません。Docker Content Trust は TUF を活用し、鍵の階層にまたがる責任を分離します。これは、あらゆる鍵を喪失（オフラインのものを除外）しても、それによりシステムの致命的なセキュリティにならないことを意味します。

Docker Content Trust は提供者に対し、鍵を透過的に入れ替えるので、利用者は漏洩した鍵をシステムから効率的に削除します。鍵の入れ替え機能によって、利用者に混乱させることがなく、提供者は鍵の入れ替えを積極的に行うことができ、未知の鍵の漏洩から守ることができるようになります。

■ Notary：安全なイメージ内容の配布

Docker Content Trust を使うことで、Docker Engine に Notary を統合できるようになります。Notary とは安全なイメージの公開と、イメージ内容を検証するためのツールであり、安全ではないネットワーク上でもイメージが配布できるようになります。DockerCon の「Infrasturucture plumbing」（インフラ設備）で紹介したように、Notary は内容に関する仲裁を行い、必要な誰もが電子署名を実装・検証し、そしてダウンロードできるようになります。Notary の主な目的は、ソフトウェア配布に関する現状を一歩先に進めるためであり、現在のパッケージに関するセキュリティ保障を簡単なコマンドライン・ツールで実現することです。

■ 更新フレームワーク（TUF; The Update Framerowk）

Notary は内部的に更新フレームワーク(TUF) を使うことで、ソフトウェアの配布と更新に関する問題に対して、安全な設計をもたらします。TUF は開発者に対して、安全なソフトウェア更新システムの問題解決の手助けとなるよう、柔軟なセキュリティ・フレームワークを提供します。つまり、アプリケーションはソフトウェア更新プロセスにおける、全ての既知の攻撃に対して安全になります。TUF を使うことにより、Notary と Docker Content Trust は鍵の漏洩が起こっても（システムが）生き残れる優位性があり、信頼できないミラー上でも安全に更新できるようになり、リプライ攻撃やダウングレード攻撃などからも守ることができます。

TUF に関するより詳細な情報については、以下をご覧ください（英語）：

• 更新フレームワーク(TUF)の仕様
• ミラー上のパッケージ・マネージャに対する攻撃
• パッケージ管理の安全性
• ソフトウェアの更新システムにおける鍵漏洩からの生き残り

■ まとめ

Docker Content Trust の導入は Docker プラットフォームにおける中心的な役割であり、開発者が安全に配布アプリケーションを構築できるよう手助けするための重要なマイルストーンです。今日から誰もが Docker イメージに対して署名と検査を行えるようになります。私達は Docker Hub 上の全ての公式レポジトリ上のイメージに対して署名を行いました。これにより、皆さんがアプリケーションを構築するにあたり、信頼できるイメージの基本セットを利用できるようになります。

ですので、皆さん、署名してみましょう！ Docker Engine 1.8 の一部分として、Docker Content Trust を試してみる（英語）ほか、より深く理解したい場合は Notary をご確認ください。

• Docker Toolbox をダウンロードし、 Docker を使い始める
• Docker 1.8 に関して詳しく知る
• Content Trust に関するドキュメントを読む