kern

kern: 信頼できないコードや AI が生成したコードを含む、あらゆるワークロードのための高速なルートレスサンドボックス兼仮想リソースランタイム。

デーモン不要の 1.52 MB のバイナリ1つで、カーネルが強制する本物のコンテナを約 3.5 ms で起動。

_{アイドル時は RAM 0 · デーモンもソケットも起動するものもなし · 静的バイナリ1つ、Rust の依存関係は libc のみ}

# install the release binary (static, 1.52 MB, checksum-verified by the script)
curl -fsSL https://raw.githubusercontent.com/getkern/kern/main/install.sh | sh

# a throwaway shell in a real OCI image: rootless, kernel-enforced, a few ms
kern box dev --image alpine -it -- sh

_{Windows ネイティブには非対応: WSL2 を使用してください。インストール。}

kern とは

リソースを管理する1つのバイナリ。その第一が分離です。 だからこそ、比較表に kern の行が1つだけということはありません。kern はコンテナランタイム、サンドボックス、リソーススライサー、スタックランナーを1つに兼ね備えており、デーモンなしの 1.52 MB です。

• 本物のコンテナ。 本物の OCI イメージ: pull、Dockerfile からの build、commit、push、save/load。イメージからのボックスは約 3.5 ms で起動します。
• 常にルートレスなサンドボックス。 User、PID、mount、network、UTS、IPC 名前空間、オーバーレイまたは読み取り専用ルートの pivot、デフォルト拒否の seccomp 許可リスト、cgroup v2 による制限。1つのフラグ --security-profile untrusted が堅牢化バンドル全体です。
• 分離だけでなくリソースプロファイル。 CPU (vcpu:)、メモリ、ディスク (vdisk:)、デバイス (vgpio:) を kern.toml に一度宣言し、名前でアタッチします。kern run はサンドボックスなしで、ホスト上のプロセスに同じ制限を適用します。docs/RESOURCES.md
• kern 独自形式または Docker 形式のスタック。 kern compose <file> up は （上記のリソースプロファイルを持つ テーブル）または既存の をそのまま読み取ります。1スタックにつき1ポッドで、サービスは名前で相互に到達します。

Rust の依存関係ツリー全体は libc のみです。JSON と OCI マニフェストは手書きでパースし、pull は TLS スタックをリンクする代わりに、マシン上に既にある curl と tar に外部コマンドとして委ねます。（1.52 MB はサイズ最適化されたリリースビルドで、ソースからの素の cargo install は 1.91 MB です。）

kern ではないもの

• ハイパーバイザーではありません。 境界は Linux カーネルなので、カーネルの権限昇格バグは脱出につながります。Docker と Podman も同じ条件であり、だからこそ gVisor や Firecracker が存在します。

  タグラインと合わせて読むと、これは両面から見た1つの線です。kern が対象とするのは、あなたが実行を選び、爆発半径を自分で負う信頼できないコードや AI が生成したコードです（エージェントのツール呼び出し、CI ジョブ、ビルドステップ、コードセル）。対象外なのは、他のテナントにもサービスを提供するカーネル上での、見知らぬ人からの悪意あるコードのマルチテナント実行です。kern は常にルートレスで起動しますが、Docker ではオプトインです。

• userns のトレードオフからは自由ではありません。 その分離は非特権ユーザー名前空間の上に構築されており、これはカーネル LPE バグの温床です。SECURITY.md はあらゆる主張に先立ってこれを明記しています。

• マウントしたものの周囲に壁を張りません。 -v $HOME:/host はボックスにあなたのホームディレクトリを与えます。マウントはあなたが下す信頼の判断であり、kern が強制する境界ではありません。--net host と --privileged は名前の通りオプトアウトです。（kern がバインドを拒否する唯一のパスは、自身のランタイムレジストリです。）

• Docker Engine の再実装ではありません。 Docker の フォーマット を話しますが、API は話しません。オーバーレイネットワーク、プラグイン、Swarm はありません。互換性マトリクス: docs/DOCKER-COMPAT.md。

• Kubernetes ランタイムではありません。 CRI はありません。containerd または CRI-O を使用してください。

• GPU スライスは提供していません。 ロードマップ にあり、このエディションには GPU コードが含まれていないため、現時点で信頼すべきものも攻撃対象もありません。

未対応・未実装の事項は、あなたが探し回らなくて済むように OPEN_ITEMS.md にまとめられています。

インストール

kern には、非特権ユーザー名前空間と cgroup v2 を備えた Linux カーネルが必要です。Linux、WSL2、ARM ボード（Raspberry Pi · Jetson · Arduino UNO Q）で動作します。Windows ネイティブビルドはなく、WSL2 を使用してください（kern にはプリビルド済みの WSL rootfs が同梱されています）。

最も手軽な方法はリリースバイナリです。静的ファイル1つでツールチェーン不要、しかもスクリプトがインストール前に SHA256 を検証します。

curl -fsSL https://raw.githubusercontent.com/getkern/kern/main/install.sh | sh

x86_64 か aarch64 を自動で選択し、~/.local/bin（root の場合は /usr/local/bin、または KERN_INSTALL_DIR）にインストールします。チェックサムが一致しないダウンロードはインストールを拒否します。代わりに手動で検証するなら2行です:

curl -fsSLO https://github.com/getkern/kern/releases/latest/download/kern-x86_64-unknown-linux-musl.tar.gz{,.sha256}
sha256sum -c kern-x86_64-unknown-linux-musl.tar.gz.sha256 && tar xzf kern-x86_64-unknown-linux-musl.tar.gz

もう1つの方法はソースからです。依存関係ツリー全体が1つのクレート（libc）なので短時間で済みます。デスクトップ（i7-14700KF）では clone、build、install に 36 秒かかりましたが、小型 ARM ボードではもう少しかかります。

# if you do not have Rust yet
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

cargo install --git https://github.com/getkern/kern getkern --locked

これにより kern が ~/.cargo/bin に配置され、rustup が PATH に追加します（kern が見つからない場合は、新しいシェルを開くか source "$HOME/.cargo/env" を実行してください）。

リリースには aarch64 バイナリ、Windows 用 .exe シム、プリビルド済み WSL rootfs も同梱されており、それぞれに独自の .sha256 があります。タグは GPG 署名され、独立してタイムスタンプされています（provenance/）。

kern doctor は、試す前にこの環境でボックスが実行できるかどうかを教えてくれます。ボード、WSL2、詳細版: docs/INSTALL.md。よくある質問（Docker、bubblewrap、youki、E2B、Windows、脅威モデル）: docs/FAQ.md。

クイックスタート

kern box dev --image alpine -it -- sh              # a throwaway shell in a real OCI image
kern run --memory 256M --cpus 0.5 -- ./crunch      # cap a process, no sandbox
kern box svc --image nginx:alpine -d -p 8080:80 \  # a service: published, restarted, health-checked
  --restart --health-cmd 'wget -qO- localhost:80' -- nginx -g 'daemon off;'
kern ps                                            # what is running, with PORTS and HEALTH
kern exec svc -it -- sh                            # shell into it
kern stop svc                                      # its signal, its grace, then the code it exited with
kern top                                           # live TUI: boxes, CPU/RAM, profiles, volumes
kern compose stack.toml up                         # a multi-box stack (examples/) or a compose.yml
kern compose stack.toml down                       # and take it down again

信頼できないコードには、バンドル全体を1つのフラグで指定:

kern box job --image python:3.12-slim --security-profile untrusted --memory 256m \
  -v ./job:/w -- python3 /w/x.py

--security-profile untrusted は、seccomp 許可リスト + --cap-drop ALL + --read-only を1つにまとめたオプトインフラグです（お好みで個別に指定することもできます）。--require-limits を追加すると、メモリ / pids の制限が実際に強制されない限り起動を拒否します。要求しない限りネットワークなし、危険なケーパビリティは破棄、seccomp は常に有効。それぞれが1つのことを行う実行可能な例が90個あります: examples/。

読み取り系の全コマンドは JSON でも応答するため、テーブルをパースする必要はありません:

kern ps --json | jq '.[] | select(.health == "unhealthy") | .name'
kern volume ls --json          # ps · images · stats · inspect · builds · pod ls · config list · diff

Docker Desktop なしで使う、あなたの Docker Compose スタック

kern は docker-compose.yml を解釈します。既存のスタックを指定するだけで、kern compose up がデーモンも Docker Desktop もなしで実行します。Linux、WSL2、ARM ボードで同じように動作します。

# compose.yaml - a real stack, unchanged
services:
  db:
    image: postgres:alpine
    environment: { POSTGRES_PASSWORD: secret, POSTGRES_DB: app }
  web:
    image: adminer
    ports: ["8080:8080"]
    depends_on: [db]

kern compose compose.yaml up

両方の公式イメージが起動し、web はサービス名で db に到達し、ポートはホストに公開されます。ウォーム状態（イメージキャッシュ済み）では Web 層が 約 0.3 秒 で応答し、スタックのコストは postgres と adminer が実際に使う分だけ（ここでは約 66 MB）で、その上にデーモンはゼロです。一方 Docker Desktop は、最初のコンテナを起動する前からバックグラウンド VM が存在します。

非 root ユーザーに切り替わる公式イメージ（postgres、redis など）には uidmap と /etc/subuid の行が必要で、外向きのイメージ pull には pasta が必要です。どちらも開発マシンでは apt install 1つで導入でき、kern doctor が不足しているものを教えてくれます。これはローカル開発ループであり、本番オーケストレータではありません。Swarm もオーバーレイネットワークもありません。

組み込み: Python & Node

エージェントや LLM が生成したコードを自分のプログラムから実行するには、kern-sandbox を使います。これは kern バイナリの薄く依存関係ゼロのラッパーです。各呼び出しは新しい分離ボックスで実行されます。ネットワークオフ、メモリと pid の制限、ケーパビリティ破棄、出力の上限、そしてバインディング自身が強制するタイムアウト。

pip install kern-sandbox        # PyPI   · needs the `kern` binary above, on PATH or $KERN_BIN
npm  install kern-sandbox       # npm    · same

from kern_sandbox import run_code

r = run_code("import platform; print(platform.python_version())")
print(r.stdout)          # ran in a fresh box; a timeout / OOM / blocked escape is data on r.fault

• 障害は例外ではなくデータです: タイムアウト、OOM キル、ブロックされたシステムコールは、例外ではなく結果のフィールドです。デフォルトでは呼び出しごとに新しいボックス。Sandbox は呼び出しをまたいでワークスペースを保持し、ウォームな kernel() はサブミリ秒のセルのために1つのインタープリタを保持します（意図的に弱い分離）。
• Jupyter カーネルなしでのリッチな結果: 最後の式、display()、matplotlib の図が、ノートブックのセルのようにキャプチャされて返ってきます。
• MCP サーバー（kern-mcp）を同梱: 依存関係ゼロの stdio サーバーで、Claude Desktop、Cursor、その他の MCP クライアントにローカルコードインタープリタを提供します。クライアントにこれを指定します:

{ "mcpServers": { "kern": { "command": "kern-mcp" } } }

ツール: run_code（python/bash/node）、write_file、read_file、list_files。各呼び出しはネットワークオフの新しいボックスで、ファイルはディスク上のワークスペースに呼び出しをまたいで保持されます。セットアップコマンド、イメージ、その他のオプション: bindings/python/README.md。

Python と Node の完全な API: bindings/python/README.md · bindings/node/README.md。

リソースプロファイル

スライスは ~/.config/kern/kern.toml に一度宣言し、名前でアタッチします。サンドボックス化されたボックスにも素のプロセスにも、同じトークンで適用できます。

3種類あります: vcpu:（CPU とメモリ）、vdisk:（サイズ上限付きスクラッチディスク）、vgpio:（デバイスノード）。そのうち2つと、それらを切り出すアンカー:

[[cpu]]                     # the host budget a slice is carved from
id    = "cpu:0"
cores = 8.0

[[vcpu]]                    # 1.5 cores and 512 MiB  ->  attach as  vcpu:heavy
name    = "heavy"
backend = "cpu:0"
cpus    = 1.5
memory  = "512m"

[[gpio]]                    # a controller anchor
id = "gpio:0"

[[vgpio]]                   # exactly one device node ->  attach as  vgpio:sensor
name    = "sensor"
backend = "gpio:0"
i2c     = ["/dev/i2c-1"]

kern validate ~/.config/kern/kern.toml       # check it before anything runs
kern box train --image alpine vcpu:heavy vdisk:scratch -- ./train.sh
kern run vcpu:heavy -- ./train.sh            # the same slice, no sandbox
kern box iot --image alpine vgpio:sensor -- ls /dev

プロファイルは合成できます。複数を1つのボックスにアタッチでき、明示的なフラグはプロファイル自身の値より優先されます。すべてのキーは CLI フラグと同じ綴りなので、cpus は --cpus、memory は --memory です。宣言されていないプールを参照するバックエンドは、ボックス実行時ではなく設定読み込み時に拒否されます。フィールドごとのスキーマは docs/RESOURCES.md にあります。

vdisk: は、kern がルートレスで動作する場合はバックエンドの指定にかかわらず RAM バックの tmpfs になり、特権で動作する場合は実際のクォータを持つ ext4-on-loop イメージになります。kern は推測に任せるのではなく、プロファイルごとにどちらかを明示し、サイズ上限はどちらの場合も強制されます。

vgpio: はライン単位ではなくチップ単位です。 pins を指定すると /dev/gpiochipN 全体がバインドされ、そのキャラクタデバイスはそのコントローラのすべてのラインを公開します。pins = [17] はボックスをライン 17 に制限しません。カーネルにはライン単位のマウント境界がないため、ピンリストは境界ではなく協調的なメタデータだからです。上記の i2c のようにデバイスノードを名前指定すると、そのノードだけが許可され、それ以外は何も許可されません。

kern vs Docker vs Podman

パフォーマンス

Intel i7-14700KF、Linux 7.0.0、リリースバイナリ、自分で実行できるスクリプト: python3 examples/benchmark.py。結果は CPU、カーネル、ファイルシステムによって異なります。

3000 個を同時に起動すると約 2.2 秒かかり、稼働中のボックス1つのメモリコストは約 0.3 MB です。

正直に言うべき点が2つあります。単発レイテンシで決定的に勝つ人はいません: unshare + exec の下限は 1〜2 ms なので、最上位層はすべてそれ自身のノイズの範囲内にあります。また bubblewrap はイメージもケーパビリティもライフサイクルもないランチャーです。意味のある差は、2桁上のエンジンとの差です。

方法論、フェーズごとの内訳、ボードの数値、すべての注意点: BENCHMARKS.md。

セキュリティ

名前空間、pivot_root、exec 前に破棄される16の危険なケーパビリティ、デフォルトで常時有効な seccomp 許可リスト（moby 自身のデフォルトフィルタから、kern の 35 の脱出用システムコールを除外したもの。これらは引き続きハードキル対象です。検証済みセット外のシステムコールは ENOSYS を返し、より広範な拒否リストへのオプトアウトは KERN_SECCOMP=denylist で行います）、cgroup v2 の制限（--require-limits は制限がバインドされない限り起動を拒否）、そしてデフォルト拒否の /dev。境界がカーネル強制ではなく協調的な場合、SECURITY.md はその旨を明記し、バイパス方法を挙げています。

盲目的に信じる必要はありません。pentest/ には、kern 自身の報告ではなくカーネルに対してこれらの境界を検証する4つの敵対的スイートが含まれており、レジストリアカウントやネットワークなしで実行できます。

sh pentest/run-with-local-registry.sh ./target/release/kern pentest/pentest-ports.sh

脆弱性は GitHub Security Advisories または [email protected] まで私的に報告してください。

ドキュメント

ステータス

コアは完成しています。上記のすべてが現在動作しています: 840 の Rust、78 の Python、61 の Node テスト、clippy クリーン、cargo-deny クリーン、実ハードウェア（Linux、WSL2、Raspberry Pi 5、Jetson Orin Nano、Arduino UNO Q）で検証済み。v0.7.0 が最初の公開リリースです。 CLI と設定の表面はまだ変更される可能性がありますが、常に CHANGELOG.md で告知されます。

コントリビューション

Issue とプルリクエストを歓迎します。CONTRIBUTING.md にワークフローとゲートがあります。コントリビューションは CLA の対象です。

メンテナー

Alex（@realexhub）。コミットはプロジェクトのコミット用アイデンティティである @getkerndev から行われます。

コミットは署名されていませんが、リリース TAG は署名されています。 検証すべきはそれです: provenance/ の鍵を使って git verify-tag v0.7.0 を実行します。そのフィンガープリントは SECURITY.md にあります。

ライセンス

Apache-2.0。LICENSE と TRADEMARK.md を参照してください。