最初のAGELAIOSモジュールを1時間で作る
エコシステム
ミッションシステムの拡張を、数週間にわたるリバースエンジニアリングから始めるべきではありません。開発チームには、明確な契約、再現可能なツールチェーン、そしてコードが意図どおりに動作することを証明できる安全な環境が必要です。
AGELAIOSはこの原則を中心に設計されています。モジュール開発フローでは、生成済みプロジェクトから、エミュレートされたノード上で動作する署名済みパッケージまでを、明示的な8段階で進みます。各段階は、次へ進む前に確認できる証拠を生成します。
この記事における1時間という目標は、ガイド付きフローの設計目標であり、公開済みベンチマークではありません。正式な計時手順を定義して反復実施した段階ではないため、測定済み性能としては提示しません。ただし、専用ハードウェアなしで実行できます。チーム自身が再現し、時間を測り、開発者体験を評価できます。
本ガイドでは、最小限のhello-trackモジュールを使って全工程をたどり、その後、本番で最も重要な2つの判断、すなわちモジュール契約と分離プロファイルを説明します。
開始前に必要なもの
この演習には3つの要素が必要です。
- ソブリンインスタンスガイドの手順でクローンし、検証したAGELAIOS参照リポジトリ。
- そのリポジトリからビルドした
agelaiosコマンドラインツール。 - エミュレートされたノード。プラットフォームはx86-64とARM64でエミュレートできるため、このフローに対象実機は不要です。
以下のコマンド出力は、期待される形式を示します。正式な参照情報は、リポジトリのドキュメントです。例ではRustを使用し、ノードの共通作戦状況図へデモ用トラックを発行する小さなモジュールを作成します。テンプレートが対応する他の言語でも、生成フローは同じ順序に従います。
発想から稼働モジュールまでの8つの管理された手順
1. 有効なプロジェクトから始める
agelaios new hello-track --lang rust --isolation wasiagelaios newは、空のディレクトリ以上のものを生成します。記入済みのmodule.yamlマニフェスト、gRPCサービスのスケルトン、テスト例、選択対象向けのビルド構成を作成します。
テンプレートは、開発者が変更する前の状態でコンパイルとテストに成功するよう設計されています。最初の工学作業は、プラットフォームの期待事項を再構築することではありません。すでに有効な構造の中で、有用な挙動を実装することです。
2. 宣言を検証する
agelaios lintマニフェストは、モジュールのアイデンティティ、要求するケイパビリティ、参照するインターフェースを定義します。agelaios lintは、これらの宣言をモジュール契約スキーマに照らして確認します。
無効なアイデンティティ、未知のケイパビリティ、欠落したインターフェースがあれば、コンパイル前のこの段階でフローを停止します。早期の拒否はフィードバックループを短縮し、配備時まで問題を潜伏させる代わりに、レビュー担当者が調査すべき規則を正確に示します。
3. 分離された成果物を生成する
agelaios build --target wasm32-wasiビルドコマンドは、選択した分離対象向けにモジュールをコンパイルします。この例で期待される結果は、単一のhello-track.wasm成果物とそのダイジェストです。
WASIモジュールの場合、同じ成果物をx86-64ノードとARM64ノードで使用できます。この可搬性により、チームがビルド、配布、検証すべきアーキテクチャ固有パッケージの数を減らせます。
4. 代表的な制約下で試験する
agelaios testローカルテストは、ノードと同種のサンドボックス内で、同じケイパビリティ制約を適用して実行されます。宣言していないファイル、ソケット、クロックを開こうとするモジュールは、インストール後ではなくローカル試験中に失敗するはずです。
目的は明快です。開発環境と実行環境の差を縮めます。成功結果は、本番モジュールに必要な広範な検証に代わるものではありませんが、工程の早期に関連性の高い証拠を提供します。
5. 発行者鍵を作成する
agelaios keygen --algo ml-dsa-65 --out ./keys/publisherこのコマンドは、FIPS 204に基づくML-DSA-65鍵ペアを作成します。秘密鍵はローカルに留まり、リポジトリにもPenrose Tacticalにも送信されません。
この演習にはローカル鍵で十分です。運用フリートへ公開するには、鍵をインスタンスの公開鍵基盤へ登録し、運用者のポリシーに従って管理する必要があります。
6. アイデンティティと内容を結び付ける
agelaios sign --key ./keys/publisher --artifact out/hello-track.wasm署名によって、成果物とマニフェストを対象とする分離署名が生成されます。これがフローの中心にある信頼判断です。
AGELAIOSノードは、署名が、そのインスタンスのモジュールストアで承認された発行者鍵へ連鎖していない限り、モジュールを拒否します。コンパイルできることや、誰かがノードへ転送できることだけで、コードが信頼済みになることはありません。
7. 配布単位を作成する
agelaios pack --out hello-track-0.1.0.ocmpackコマンドは、成果物、マニフェスト、署名を1つのモジュールアーカイブへまとめます。このアーカイブは、モジュールストアが受け入れ、インスタンスのTUFリポジトリを通じて配布する単位です。
これらを一体化することで、承認対象とインストール向けに配信される対象を同一に保ちます。また、サプライチェーンが識別、署名、監査するための安定した単位を得られます。
8. エミュレートされたノードへインストールする
agelaios emu up --profile node-x86_64
agelaios install hello-track-0.1.0.ocm --target emuエミュレートされたノードは署名を検証し、要求されたケイパビリティをローカルポリシーと比較し、モジュールをサンドボックスへ読み込み、ローカルカタログへ登録します。
期待される結果は、デモモードのノード共通作戦状況図からインターフェースを確認できる稼働モジュールです。この時点で、フローは8つの確認可能な結果、すなわちプロジェクトツリー、lint判定、成果物、テスト結果、鍵ペア、署名、アーカイブ、稼働モジュールを生成しています。
この証拠の連鎖は、速度だけより価値があります。開発者に短い成果経路を提供しながら、運用者が必要とする統制を維持します。
失敗もフローの一部である
信頼できるツールチェーンは、成功方法だけでなく失敗方法も示さなければなりません。AGELAIOSのフローは、問題を理解して修正できる段階で拒否するよう設計されています。
マニフェストが無効なら、ビルド前にlintが該当フィールドと違反規則を特定します。未対応のケイパビリティを、インストール時の予期しない問題ではなく、契約上の問題として扱います。
テストが失敗すれば、署名とパッケージ化の前にフローを停止します。ローカルテストのサンドボックスはノードのケイパビリティ制約を適用するため、未宣言のアクセスは、開発者が診断できる場所で失敗するはずです。
署名が無効なら、エミュレートされたノードがアーカイブを拒否し、理由を記録します。典型的な原因は、信頼されていない鍵、署名後に変更された成果物、整合しなくなったマニフェストです。エミュレータには、未検証モジュールを信頼経路へ強制投入する抜け道はありません。このチュートリアルは、運用フリートで期待されるものと同じ信頼原則を試します。
権限をレビュー可能にする契約
すべてのAGELAIOSモジュールは、3つの中心セクションを持つ宣言型マニフェストで定義されます。
identity:
name: hello-track
version: 0.1.0
publisher: example-ltd
capabilities:
network: [mesh.tracks.publish]
storage: [state.local]
interfaces:
- grpc: agelaios.tracks.v1.TrackSourceidentityセクションは、モジュール名、バージョン、発行者を示します。capabilitiesは、ネットワーク、ストレージ、ハードウェアアクセスを含め、モジュールがプラットフォームへ要求するものを記述します。interfacesは、公開または利用するサービスを識別します。
実行インターフェースは、単一の型付き・版管理済み定義から生成されるgRPC契約を使用します [1]。agelaios.tracks.v1のようなインターフェースは、マニフェスト内で明示されます。契約が進化した場合、既存モジュールが依存する契約を密かに変えず、新しいバージョンを導入できます。
このモデルの商業的価値は実務的です。レビュー担当者はマニフェストを読むことで、要求権限を理解できます。インスタンス運用者は同じ文書へ承認ポリシーを適用できます。開発者は実装を書く前に統合境界を把握できます。
宣言されていないものは何も仮定されません。マニフェストにないアクセスは実行時に拒否され、gRPC契約にない挙動はモジュール間インターフェースに含まれません。これは、ランタイム構成を明示的かつ検査可能な文書で表す、標準化コンテナ仕様の広い原則にも従います [6]。
ワークロードに応じて分離を選ぶ
分離方式は、プロジェクト生成時に選択します。性能、互換性、封じ込めに万能の最適解はないため、AGELAIOSは3つのプロファイルを提供します。
厳格に管理されたプラットフォームコード向けのネイティブ実行
nativeプロファイルは、namespaces、cgroups、seccompなどのLinux機構で制約したプロセスとしてモジュールを実行します。システムへ直接アクセスでき、3プロファイルの中で最も低い分離境界です。
このトレードオフは、ハードウェアまたはリアルタイムアクセスを必要とするプラットフォームモジュールやワークロードに適します。同時に、最も高い信頼水準を要求します。nativeモジュールは、プラットフォームコンポーネント、またはインスタンス運用者の完全なセキュリティレビューを通過したコードに限定されます。
システムレベルの依存関係向けMicroVM
microVMプロファイルは、Firecrackerが示した軽量仮想化モデルに従い、最小限の仮想マシン内でモジュールを実行します [3]。モジュールはゲストカーネルを持ち、WASIに自然に収まらないシステム依存関係を含められます。
より強い境界にはコストがあります。各microVMは、他のプロファイルより多くのメモリを必要とします。そのため、オペレーティングシステム互換性またはハードウェア仮想化境界を必要とするワークロードに対して、測定を伴って選ぶ方式であり、無条件の既定値ではありません。
可搬性とケイパビリティを重視するモジュール向けWASI
WebAssembly/WASIプロファイルは、モジュールをWebAssemblyへコンパイルし、WASI互換ランタイムで実行します [2][4]。ファイル、ソケットなどのリソースは、明示的なケイパビリティを通じて公開されます。そのため、サンドボックスはマニフェストに示された意図と同じ内容を強制できます。
WASIはアーキテクチャ可搬性も提供します。モジュールとその依存関係が選択したWASI対象に対応していれば、1つのモジュール成果物を異なるノードアーキテクチャで使用できます。WebAssembly Component Modelは、言語境界に型付きインターフェースを追加します [5]。
このチュートリアルでは、コネクター、融合関数、計算処理といったサードパーティーのデータ処理モジュールに推奨する既定値としてWASIを選びます。既存ソフトウェアスタックが独自のシステム依存関係を必要とする場合はmicroVMを選ぶべきです。プラットフォームレベルのハードウェア要件またはリアルタイム要件によって直接アクセスと対応するセキュリティレビューが正当化される場合は、native実行が適します。
選択したプロファイルは、マニフェストとモジュールストアに記録されます。変更すると新しいバージョンになり、それ自体を評価し承認する必要があります。
成功したプロトタイプを承認済みケイパビリティへ変える
エミュレートされたノードは、この演習の終点であって、工学プロセスの終点ではありません。運用モジュールは、対象インスタンスが定める保証、統合、承認手続きを引き続き通過しなければなりません。
このフローは、その対話に有用な出発点を提供します。モジュールはすでに、明示的な契約、再現可能な成果物、ローカルテスト証拠、発行者署名、宣言済み分離境界を備えています。これらの統制は運用適合性を保証しませんが、モジュールを評価しやすくし、より安全に導入できるようにします。
チームは、有用で署名済み、かつ適切に分離されたモジュールをプロジェクトのコミュニティカタログへ提供できます。インスタンス運用者へ提案することも、Penrose Tacticalと統合経路を検討することもできます。モジュラープラットフォームを採用する最大の理由は、すべての拡張が無労力になることではありません。拡張が構造化され、レビュー可能で、反復可能になることです。
自分たちのユースケースでこのフローを実行してください。時間を測り、すべてのゲートを確認し、得られた証拠が自社の工学基準を満たすか判断してください。
参考文献
- gRPC Authors, “Introduction to gRPC”, 2024.
- WASI Subgroup, W3C WebAssembly Community Group, “WASI, the WebAssembly System Interface”, 2024.
- Amazon Web Services, “Firecracker, secure and fast microVMs for serverless computing”, 2024.
- Bytecode Alliance, “Wasmtime Documentation”, 2024.
- Bytecode Alliance, “The WebAssembly Component Model”, 2024.
- Open Container Initiative, “OCI Runtime Specification”, 2024.