HN 日本語サマリー

← 一覧へ戻る
Web開発

ダウサーバー、スマートクライアント:QuarryによるOSイメージの配布

Dumb servers, smart clients: Distributing OS images with Quarry (amutable.com)

30 pointsby Levitating1 コメント

要約

Amutableは、OSイメージを安全に配布するための新しいツールチェーン「Quarry」を発表しました。Quarryは「ダウ(愚鈍)なサーバー」と「スマートなクライアント」という設計思想に基づき、サーバー側は静的なデータを提供するだけで、クライアント側が更新の判断や適用を行うことで、ミラーリングやキャッシュを容易にし、コストを削減します。これにより、高信頼性のLinuxシステム配布を目指します。

全文翻訳

2026年9月29日 14分読む ダウサーバー、スマートクライアント:Quarryによるイメージ配布 Aleksa Sarai著 目次 このシリーズの以前のブログ記事では、イミュータブルなイメージを構築するためのtineを紹介しました。イメージができたら、それを安全に配布する手段が必要です。この記事では、私たちの「岩のようにダウな」ソフトウェア配信ツールチェーン、Quarryを紹介します! ソフトウェア配信 Linuxシステムをユニークにしているものを考えると、まず思い浮かぶのはそのソフトウェア配信メカニズム、すなわち伝統的にはパッケージマネージャーを介したものです。システム全体でソフトウェアのインストールと更新を管理するためのグローバルシステムは、画期的なアイデアでした。多くのディストリビューションが独自のツールを構築してソフトウェアを管理・配布するようになりました。この断片化がLinuxを損なっていると主張する人もいますが、この状況はおそらく避けられないもので、異なるディストリビューションが構築したツールは、それらのプロジェクトの異なる目標を反映しています。 Amutableでは、高信頼性のLinuxシステムを提供することを目標としています。これは私たちのあらゆる側面に反映されており、ソフトウェア配信も例外ではありません。 主要な要件 ここで、主要な要件を見ていきましょう。 ダウであること。プロトコルは、クライアントへの応答を生成するためにスマートサーバーに依存しないこと。アップデートペイロードとメタデータは、「ダウ」な静的ホスティングを介して提供される静的なブロブであり、「スマートさ」はすべてクライアントに存在すること。これにより、ミラーリングの実装が非常に容易になり、キャッシュも柔軟かつ安価になり(静的ブロブはCDNのパンとバターであり、エグレスコストは「信じられないほど安い」から「無料」の範囲です)、将来の代替トランスポートメカニズムに多くの柔軟性が得られます。 きめ細かな所有権を提供する。署名と一般的な配布モデルは、署名されたデータに対して異なる「所有者」を許可する必要があります。私たちが本当に避けたい主要な落とし穴は、「サードパーティ署名キー」モデルであり、すべてのサードパーティデータに対して証明書発行局のように振る舞うことを余儀なくされます。これは、不必要な管理オーバーヘッドであることに加えて、ベンダーのために署名されたオブジェクトがしばしばすべてのマシンで承認されるようになるため、全体的な認証スキームのセキュリティを低下させます。 柔軟なキーエスクローを可能にする。きめ細かな所有権の一部として、私たち(または他の当事者)によるキーエスクローから完全なキー所有権への移行が、クライアントに影響を与えることなく可能であるべきです。これは当然のことのように思えるかもしれませんが、ハードウェアベースの署名キーはしばしばエクスポート不可能であったり、相互運用性がない可能性のあるカスタムプロトコルに依存したりするため、考慮することが重要です。また、すべての署名モデルが、署名するエンティティを安全に完全に置き換えることを許可しているわけではありません。 自律的であること。アップデートスキームは、マシンが完全に自律的なアップデートを実行できるように、堅牢で説明的なものである必要があります。同時に、ステージングロールアウトやブルーグリーンデプロイメントなど、最新のデプロイメントシステムに期待されるすべてのメカニズムを提供する必要があります。 きめ細かなアドレス指定をサポートする。数百万台のマシンに汎用オペレーティングシステムアップデートをプッシュできることに加えて、よりきめ細かなマシンのグループ(個々のマシンさえも)にプッシュできる必要があります。これにより、ソフトウェア配信メカニズムをより一般的な制御およびプロビジョニングメカニズムとしても使用できます。 必要に応じて運用する。きめ細かなアドレス指定の裏返しは、各組織のフリートの構造、およびそれらの一般的なデプロイメントスキームが、リポジトリの構造に直接表されていることです。単一ノードが侵害された場合でも、攻撃者がそのノードが所有するより広い組織に関する追加情報を得ることはできません。それは、それに直接関連するプロビジョニングデータにのみアクセスできるはずです。 安全であること。言うまでもないことですが、私たちが使用するスキームは、類似のソフトウェア配布スキームに対する既知のすべての攻撃に対して安全であり、健全なセキュリティ原則を使用して構築されている必要があります。 背景 Quarryがどのように機能するかを理解するために、まず、アーティファクトのインストールと配布に利用するプロジェクトを見ていく必要があります。 systemd-sysupdate systemd-sysupdateは、主にUnified Kernel Images(UKI)とDiscoverable Disk Images(DDI)のインストールと更新に焦点を当てた低レベルのインストーラーであり、イミュータブルなイメージベースのオペレーティングシステムアップデートのための汎用スキームを提供します。ディスクパーティションへのフラッシュによるDDIのインストール、システム拡張(sysextsおよびconfexts)としてのDDIのインストール、EFIブートパーティションへのUKIのインストール、およびリモートソースからローカルターゲットへのファイルのインストールに関するその他の汎用的な機能を提供します。 注:この記事の残りの部分では、「sysupdate」はsystemd-sysupdateが使用する一般的なスキームを指し、systemd-sysupdateは実際のプログラムを指します。 Linuxの他のアップデートシステムと比較して、sysupdateはアップデートソースとターゲットのプロパティを記述するためのかなりユニークなメカニズムを持っています。これらのプロパティには、どのペイロードが存在するか、ペイロードはどのようにバージョン付けされるか、新しいペイロードはどこから取得されるか、ペイロードはどのようにインストールされるか、どのペイロードがグループで一緒に更新される必要があるかなどが含まれます。これらはすべて、ディスク上の転送ファイルによって表されます。 The Update Framework (TUF) 2000年代半ば、ソフトウェアリポジトリに対するいくつかの注目度の高い攻撃が発生し、一部の研究者が理論的に保護されるべき攻撃の種類と実際に保護されている攻撃の種類をより高レベルで検討するようになりました。彼らは、多くのソフトウェア配信システムに基本的なセキュリティ上の問題があり、キーの侵害から回復するための堅牢なメカニズムが欠けていることを発見しました。同時に、Tor Projectは同様のラインで、あらゆる種類の中間者攻撃から保護される必要があるアップデートスキームに取り組んでいました。共同論文が設計を説明するために書かれ、The Update Framework(TUF)が誕生しました。 なぜTUFか? TUFには、Quarryの堅固な基盤であると結論付けるのに役立った側面がいくつかありました。TUFの主な焦点の1つは、ソフトウェアリポジトリのキー侵害に対処する方法の問題です(記念論文のタイトルは「ソフトウェアアップデートシステムにおけるキー侵害からの回復」でした)。彼らは、ほとんどのソフトウェア配布スキームが、複数の異なる目的に使用される単一の署名キーを持つという欠陥のある所有権モデルを持っており、まれだがリスクの高い操作と一般的でリスクの低い操作の混同により、スキームのセキュリティが低下していることを認識しました。TUFは代わりに、アーティファクト公開フローのさまざまな段階を、分離された署名キーを持つ個別のロールに分離します。中心的な考え方は、オブジェクトに署名するエンティティが、その正確性に関する最も多くの情報を持っているべきであるということです。TUFはその後、どのロールのキーが侵害された場合でも、インバンドで安全に解決する方法について非常に明確な手順を提供します。 ターゲットロールは、アーティファクト名、サイズ、ハッシュのリストに署名します。従来のソフトウェアリポジトリモデルでは、ターゲットロールのキーは実際の開発者が所有することを意図しています。また、多くの異なる当事者がリポジトリでソフトウェアを動的に配布できるように、他のカスタムロール(異なる署名キーを持つ)に委任することもできます。(TUFの用語では、アーティファクトは「ターゲットファイル」と呼ばれ、「ターゲットロール」となります。) スナップショットロールは、クライアントがリポジトリ内のすべてのソフトウェアの一貫したスナップショットを見ることを保証するために、ターゲットロールのメタデータ(バージョンとハッシュ)のスナップショットに署名します。これは通常、リポジトリの発行元によって所有されます。 タイムスタンプロールは、スナップショットロールのバージョンとハッシュに署名するだけです。TUFのすべてのメタデータには、フリーズ攻撃から保護するための明示的な有効期限があります。タイムスタンプロールという非常に短い説明を持つことで、クライアントが他のロールデータを無駄に再プルする必要なしに、非常に短いTUFメタデータの有効期限を設定できます。これは通常、リポジトリの発行元によって所有されます。 ルートロールは、トップレベルのロールに署名するために許可される公開キーのセット(および各ロールに必要なキーのしきい値)の説明に署名します。これは発行元によって所有されます。