lxc
LXC 6.0.1 LTS
LXC は、よく知られ、厳しくテストされた低レベル Linux コンテナー ランタイムです。 2008 年から積極的に開発が進められており、世界中の重要な実稼働環境で実証されています。その中心的な貢献者の中には、Linux カーネル内でのさまざまなよく知られたコンテナ化機能の実装を支援した人々と同じ人もいます。
| タイプ | サービス | 状態 |
|---|---|---|
| CI (Linux) | GitHub | |
| CI (Linux) | ジェンキンス | |
| プロジェクトのステータス | CII のベスト プラクティス | |
| ファジング | OSS-ファズ | |
| ファジング | CIFuzz |
LXC の主な焦点はシステム コンテナです。つまり、VM から得られる環境にできるだけ近い環境を提供するコンテナですが、別個のカーネルの実行やすべてのハードウェアのシミュレーションに伴うオーバーヘッドはありません。
これは、ネームスペース、必須アクセス制御、制御グループなどのカーネル セキュリティ機能の組み合わせによって実現されます。
非特権コンテナーは、特権なしで実行されるコンテナーです。これには、コンテナーが実行されるカーネルでのユーザー名前空間のサポートが必要です。 LXC は、ユーザー名前空間がメインライン カーネルにマージされた後、特権のないコンテナをサポートする最初のランタイムでした。
本質的に、ユーザー名前空間は、特定の UID と GID のセットを分離します。これは、ホスト上の UID および GID の範囲と、コンテナ内の異なる (特権のない) UID および GID の範囲との間のマッピングを確立することによって実現されます。カーネルは、コンテナ内ではすべての UID と GID がホストから期待されるとおりに表示されるようにこのマッピングを変換しますが、ホスト上ではこれらの UID と GID には実際には特権がありません。たとえば、コンテナ内で UID および GID 0 として実行されているプロセスは、ホスト上では UID および GID 100000 として表示される場合があります。実装と動作の詳細は、対応するユーザー名前空間のマニュアル ページから収集できます。
非特権コンテナはセキュリティ強化であるため、当然、カーネルによって強制されるいくつかの制限が伴います。完全に機能する非特権コンテナを提供するために、LXC は 3 つの setuid コードと対話します。
それ以外はすべて、独自のユーザーまたはユーザーが所有する uid として実行されます。
一般に、LXC の目標は、カーネルで利用可能なすべてのセキュリティ機能を利用することです。これは、LXC の構成管理により、経験豊富なユーザーがニーズに合わせて LXC を複雑に調整できることを意味します。
LXC セキュリティの詳細については、次のリンクを参照してください。
原則として、正しい構成が適用されていれば、LXC はこれらのツールがなくても実行できます。ただし、そのようなコンテナの有用性は通常、かなり制限されています。最も一般的な 2 つの問題を強調します。
ネットワーク: setuid ヘルパーに依存せずに、特権のないユーザー (LXC のlxc-user-nicバイナリを参照) に適切なネットワーク デバイスをセットアップしない場合、唯一のオプションはネットワーク名前空間をホストと共有することです。これは原則として安全であるはずですが、ホストのネットワーク名前空間を共有すると、依然として分離が 1 段階少なくなり、攻撃ベクトルが増加します。さらに、ホストとコンテナが同じネットワーク名前空間を共有している場合、カーネルは sysfs マウントを拒否します。これは通常、コンテナ内の init バイナリが正しく起動できないことを意味します。
ユーザー名前空間: 上で概説したように、ユーザー名前空間はセキュリティを大幅に強化します。ただし、特権ヘルパーに依存しない場合、ホスト上で特権を持たないユーザーは、自分の UID をコンテナーにマップすることのみが許可されます。ただし、標準の POSIX システムでは、完全な機能を保証するには、65536 個の UID と GID が使用可能である必要があります。
LXC は、単純なキーのセットを使用して設定されます。例えば、
lxc.rootfs.pathlxc.mount.entry単一ドットを使用した LXC 名前空間構成キー。これはlxc.net.0などの複雑な構成キーが、 lxc.net.0.type 、 lxc.net.0.link 、 lxc.net.0.ipv6.addressなどのさまざまなサブキーをさらに詳細に公開することを意味します。粒状の構成。
LXC は、適切に設計された安定した REST API をその上に公開するコンテナー ハイパーバイザーである Incus のデフォルト ランタイムとして使用されます。
LXC は 2.6.32 以降のカーネルで実行されます。必要なのは、機能的な C コンパイラだけです。 LXC は、必要なカーネル機能を提供するすべてのアーキテクチャで動作します。これには以下が含まれます (ただし、これらに限定されません)。
LXC は、少なくとも次の C 標準ライブラリもサポートします。
LXC は常に強力な下位互換性を重視してきました。実際、API はリリース1.0.0以降壊れていません。メイン LXC は現在バージョン4.*.*です。
LXC プロジェクトは、セキュリティ問題を迅速かつ効率的に処理することで高い評価を得ています。潜在的なセキュリティ問題を発見したと思われる場合は、security (at) linuxcontainers (dot) org に電子メールで報告してください。
詳細については、をご覧ください。
私たちは常に新しい貢献者を歓迎しており、必要に応じて喜んでガイダンスを提供します。 LXC はカーネルコーディング規約に従います。これは、各コミットにSigned-off-by 」行が含まれることのみを要求することを意味します。私たちが使用するコーディング スタイルは、Linux カーネルで使用されるものと同じです。詳細な紹介は次の場所でご覧いただけます。
このリポジトリの CONTRIBUTING ファイルも参照してください。
もっとアクティブになりたい場合は、通常、irc.libera.chat の LXC IRC チャネル #lxc-dev に参加するのも良いでしょう。私たちはすべての開発を公開で行うよう努めており、新機能やバグの議論は適切な GitHub の問題または IRC で行われます。
セキュリティに重要な貢献や大幅な変更を行うことを考えるときは、通常、最初に開発者に ping を送信し、PR が受け入れられるかどうかを尋ねることをお勧めします。
LXC とその関連プロジェクトは、セマンティック バージョン管理スキームに厳密に従っています。
最新リリース バージョンのソースは、いつでも次からダウンロードできます。
オンラインで最新のソースコードや変更履歴を閲覧できる
ディストリビューション固有の詳細を考慮せずに、単純な
meson setup -Dprefix=/usr build
meson compile -C build
通常は十分です。
サポートが必要な場合、LXC プロジェクトはいくつかのオプションを提供します。
私たちは次の場所でディスカッション フォーラムを維持しています。
サポートが受けられる場所。
irc.libera.chat の #lxc で私たちを見つけることができます。
2 つの LXC メーリング リスト アーカイブの 1 つをチェックして、興味があれば登録できます。
