サンドボックスコンテナは、独立したカーネルを持つ軽量 VM で Pod を実行し、コンテナエスケープがホストに影響を与えるのを防ぎます。
背景情報
サンドボックスコンテナは、信頼できないアプリケーションの分離、障害分離、パフォーマンス分離、マルチテナントのワークロード分離などのシナリオに適しています。パフォーマンスへの影響を最小限に抑えながらセキュリティを強化し、ロギング、モニタリング、弾力的スケーリングなどの機能において Docker コンテナと同様のユーザーエクスペリエンスを提供します。
Kata Containers と比較して、サンドボックスコンテナはストレージ、ネットワーキング、安定性が向上しています。
アーキテクチャ
主な利点
Sandboxed Container V2 は、軽量 VM 技術をベースにした Alibaba Cloud の次世代セキュアコンテナランタイムです。V1 と比較して、強力な分離を維持しつつ、オーバーヘッドを 90% 削減し、起動速度を 3 倍に、単一マシン密度を 10 倍に向上させました。
-
軽量 VM を使用して、サンドボックス間に強力な分離を提供します。
-
従来の runC コンテナとのアプリケーション互換性を提供します。
-
runC コンテナのアプリケーションパフォーマンスの最大 90% を実現します。
-
virtiofs を介した NAS、クラウドディスク、OSS ボリュームのマウントと共有をサポートします。NAS は直接アタッチメントもサポートします。
-
モニタリング、ロギング、ストレージにおいて runC と一貫したユーザーエクスペリエンスを提供します。
-
RuntimeClass (runC および runV) をサポートします。
-
広範な技術的専門知識を必要とせず、簡単に使用できます。
-
コミュニティ版の Kata Containers と比較して、より高い安定性を提供します。
ACK サンドボックスコンテナと Kata Containers の比較
|
パフォーマンス |
パフォーマンスカテゴリ |
ACK サンドボックスコンテナ V2 |
コミュニティ版 Kata Containers |
|
サンドボックスの起動速度 |
約 150 ms |
約 500 ms |
|
|
サンドボックスの追加オーバーヘッド |
低い |
高い |
|
|
コンテナの RootFS |
virtio-fs、パフォーマンス：☆☆☆☆ |
|
|
|
コンテナボリューム |
HostPath/EmptyDir |
virtio-fs、パフォーマンス：☆☆☆☆ |
|
|
クラウドディスクのブロックストレージ |
virtio-fs、パフォーマンス：☆☆☆☆ オンラインスケーリング (リサイズ)、コンテナ I/O モニタリング、ブロック/RAW デバイス、クラウドディスクのキュー設定などの機能はサポートされていません。 |
||
|
NAS ファイルストレージ |
Samba のマウントとアンマウント、ゴミ箱、クォータ容量制御、容量/I/O モニタリング、オンラインスケーリングなどの機能はサポートされていません。 |
||
|
OSS オブジェクトストレージ |
virtio-fs、パフォーマンス：☆☆☆☆ |
||
|
ネットワークプラグイン |
|
Flannel |
|
|
モニタリングとアラート |
|
サンドボックスコンテナ Pod のディスクとネットワークの監視メトリクスが不足しています。 |
|
|
安定性 |
☆☆☆☆☆ |
☆☆ |
|
利用シーン
シナリオ 1：サンドボックスコンテナ (runV) を使用した信頼できないアプリケーションの分離
-
runC コンテナのセキュリティリスク
-
名前空間と cgroup による分離を使用するコンテナは、攻撃対象領域が広くなります。
-
ノード上のすべてのコンテナはホストカーネルを共有します。カーネルの脆弱性が悪用されると、悪意のあるコードがホストにエスケープし、プライベートネットワークに侵入し、特権コードを実行し、サービスを妨害し、データを盗む可能性があります。
-
アプリケーションの脆弱性によっても、攻撃者がプライベートネットワークに侵入する可能性があります。
以下の対策により、runC コンテナのセキュリティリスクを軽減します：
-
Seccomp： システムコールをフィルタリングします。
-
SELinux： コンテナのプロセス、ファイル、ユーザーの権限を制限します。
-
Capability： コンテナプロセスのケーパビリティを制限します。
-
Rootless モード： コンテナランタイムとコンテナが root として実行されるのを防ぎます。
これらの対策は runC コンテナのセキュリティを強化しますが、ホストカーネルの脆弱性を悪用したコンテナエスケープを防ぐことはできません。
-
-
サンドボックスコンテナ (runV) によるセキュリティリスクの分離
VM サンドボックス内のアプリケーションは、独立したゲスト OS カーネル上で実行されます。ゲストカーネルが侵害されたとしても、その影響はそのサンドボックス内に留まり、ホストや他のコンテナには影響しません。サンドボックスコンテナ (runV) と Terway NetworkPolicy を組み合わせることで、Pod レベルのアクセスポリシーを設定し、完全なシステム、データ、ネットワークの分離を実現できます。
シナリオ 2：runC コンテナにおける障害の増幅、リソース競合、パフォーマンス干渉などの問題への対処
Kubernetes はコンテナをノード上に同じ場所に配置しますが、cgroups はリソース競合を完全には解決しません。CPU 集約型や I/O 集約型のワークロードなど、リソースを大量に消費するアプリケーションはリソースを奪い合い、応答時間の変動を引き起こします。メモリリークやコアダンプなどの問題は、ノードの負荷を増大させます。ホストカーネルのバグをトリガーするコンテナはノードをクラッシュさせる可能性があり、障害はクラスター全体にカスケードする可能性があります。サンドボックスコンテナ (runV) は、独立したゲスト OS カーネルとハイパーバイザを使用して、runC コンテナにおける障害の増幅、リソース競合、パフォーマンス干渉に対処します。
シナリオ 3：マルチテナントサービス
複数の事業部門 (LOB) や部署を持つ企業では、強力なテナント分離がしばしば要求されます。例えば、金融ワークロードは、セキュリティ要件の低いアプリケーションとは別の専用環境を必要とする場合があります。従来の runC コンテナでは、信頼できないアプリケーションからのセキュリティリスクを効果的に防ぐことはできません。一般的なアプローチは次のとおりです：
-
複数のシングルテナントクラスター： 金融クラスターをセキュリティ要件の低いクラスターから分離します。
-
単一のマルチテナントクラスター： LOB アプリケーションを名前空間に分割し、LOB ごとに専用ノードを割り当てます。マルチテナント分離は、リソースクォータ、ネットワークポリシー、その他の機能に依存します。このアプローチは、複数のクラスターよりもコントロールプレーンが少なく、管理コストも低いですが、一部のテナントによる利用率の低さから生じるノードリソースの無駄を解決しません。
サンドボックスコンテナ (runV) は、信頼できないアプリケーションを VM サンドボックスに分離することで、コンテナエスケープのリスクを排除し、すべてのノードでワークロードを混在させることができます：
-
リソーススケジューリングの複雑さを軽減します。
-
ノードが複数のビジネスに対応することで、リソースの断片化を減らし、利用率を向上させ、クラスターコストを削減します。
-
サンドボックスコンテナ (runV) は軽量 VM を使用し、runC に匹敵するパフォーマンスを提供します。
制限事項
| 制約 | 詳細 |
|---|---|
| クラスタータイプ | ACK マネージドクラスターおよび ACK 専用クラスターのみ |
| クラスターバージョン | 1.16–1.34。 クラスターバージョンがこの範囲外の場合は、先に進む前にクラスターをアップグレードしてください。 |
| オペレーティングシステム | カスタムイメージはサポートされていません。 以下の OS サポートマトリックスをご参照ください。 |
| インスタンスタイプ | ECS Bare Metal インスタンスタイプのみ |
| ネットワークプラグイン | Flannel および Terway (一部のモード)。 Terway を使用する場合、専用 ENI モードと DataPath v2 はサポートされていません。 |
OS サポートマトリックス
| クラスターバージョン | サポートされている OS |
|---|---|
| 1.30 より前 | Alibaba Cloud Linux 3 および Alibaba Cloud Linux 2 (メンテナンスは停止しています) |
| 1.30 以降 | Alibaba Cloud Linux 3 のみ |