Kubernetes で信頼できないコンテナを実行する方法

IT の世界では、コンテナベースのインフラストラクチャの採用が日々増加しています。しかし、その利点、欠点、さらには制限事項が誰にとっても明らかであるわけではありません。

大企業でさえコンテナベースのインフラストラクチャに移行しつつあることを考慮すると、攻撃の可能性のある領域やデータ侵害の潜在的な影響は考慮されていません。

Docker (containerd) や LXC などのテクノロジーは、ホストされているオペレーティングシステムと同じ Linux カーネルを共有するため、真に分離されたシステムではありません。

潜在的な攻撃者にとって、大企業内にコンテナを起動することは絶好のチャンスです。しかし、コンテナ技術自体によって、私たちが自らを守ることが容易になるのでしょうか?

現在のコンテナ技術

コンテナは、すべての機能が 1 つのソフトウェアまたはオペレーティングシステムにパッケージ化されたモノリシックアプリケーションではなく、アプリケーションをパッケージ化、共有、および展開する新しい方法であることが何度も繰り返されてきました。

現在、コンテナは新しいものを活用していませんが、Linux 名前空間と cgroup の上に構築された進化形です。名前空間は仮想の分離されたユーザー空間を作成し、ファイルシステム、ネットワーク、プロセスなどのシステムリソースをアプリケーションに分離します。この抽象化により、同じホスト上で実行されている他のアプリケーションに干渉することなく、アプリケーションを独立して起動できるようになります。

したがって、名前空間と cgroup の組み合わせにより、分離された環境で同じホスト上で実行される多くのアプリケーションを確実に起動できます。

コンテナと仮想マシン

仮想マシン環境と比較すると、コンテナテクノロジが分離、移植性、合理化されたアーキテクチャの問題を解決することは明らかです。しかし、仮想マシンを使用すると、特にカーネルレベルでアプリケーションを分離できるため、ハッカーがコンテナから脱出してシステムを侵害するリスクは、仮想マシンから脱出するリスクよりもはるかに高いことを忘れないでください。

Linux カーネルの脆弱性のほとんどはコンテナに潜在的に適用されるため、影響を受ける名前空間だけでなく、同じオペレーティングシステム内の他の名前空間もエスカレートして侵害される可能性があります。

こうしたセキュリティ上の懸念から、研究者はホストから完全に分離された名前空間を作成しようと試みました。具体的には「サンドボックス化」と呼ばれ、gVisor や Kata Containers など、これらの機能を提供するソリューションはいくつかあります。

Kubernetes のコンテナランタイム

コンテナオーケストレーター Kubernetes では、この種のテクノロジーをさらに深く掘り下げることができます。

Kubernetes は、コンテナを管理するために kubelet コンポーネントを使用します。与えられた仕様に責任を持ち、時間通りに正確に業務を実行する船長と定義することができます。

Kubelet はポッド仕様を取得し、割り当てられたホスト上でコンテナとして実行し、OCI 標準に準拠している限り、任意のコンテナランタイムと対話できます (その実装は RunC です)

コンテナランタイムの仕組み

RunC はもともと Docker アーキテクチャに組み込まれ、2015 年にスタンドアロンツールとしてリリースされました。DevOps チームがコンテナエンジンの一部として使用できる、一般的な標準のクロスファンクショナルコンテナランタイムになりました。

RunC は、既存の低レベルの Linux 機能と対話するためのすべての機能を提供します。名前空間とコントロールグループを使用して、コンテナープロセスを作成および実行します。

次の段落では、ランタイムクラスとコア要素について紹介します。デフォルト値が RunC である RuntimeClass ハンドラーもあります (コンテナーランタイムとして containerd を使用する Kubernetes インストールの場合)。

ランタイムクラス

名前が示すように、ランタイムクラスを使用すると、さまざまなコンテナーランタイムを操作できます。 2014 年当時、Kubernetes で利用できる唯一のコンテナランタイムは Docker でした。 Kubernetes バージョン 1.3 から Rocket (RKT) との互換性が追加され、最終的に Kubernetes 1.5 では、標準インターフェースとすべてのコンテナランタイムの可能性を備えた Container Runtime Iterface (CRI) が導入されました。このインターフェース標準と直接対話できるため、開発者はさまざまなコンテナランタイムに適応したり、バージョンのメンテナンスについて心配したりする手間が省けます。

実際、CRI を使用すると、コンテナランタイム部分を Kubernetes から分離することができ、さらに重要な点として、Kata Containers や gVisor などのテクノロジーを containerd の形式でコンテナランタイムに接続できるようになります。

Kubernetes 1.14 では、ハンドラー属性を中核とする組み込みクラスターリソースとして RuntimeClass が再導入されました。

ハンドラーは、コンテナ作成要求を受け取り、コンテナランタイムに対応するプログラムです。

 種類: ランタイムクラス
apiバージョン: ノード。 k8s 。 io / v1
 メタデータ:
 name : #ランタイムクラス名
ハンドラー: #container ランタイム例: runc
 オーバーヘッド:
 ポッド修正:
 メモリ: "" # 64 Mi
 CPU : "" # 250 m
 スケジュール:
 ノードセレクタ:
 < キー> : < 値> # コンテナ- rt : gvisor

ハンドラーフィールドは、使用する特定のコンテナーランタイムまたは構成を指します。
オーバーヘッドを宣言すると、クラスター (スケジューラを含む) はポッドとリソースに関する決定を行う際にそれを考慮できるようになります。これらのフィールドを使用すると、この RuntimeClass でポッドを実行するコストを指定し、これらのコストが Kubernetes で考慮されるようにすることができます。
スケジューリングフィールドは、ポッドが正しいノードにスケジュールされていることを確認するために使用されます。

デフォルトでは、Docker または containerd を使用したクラスターがある場合、ハンドラーは runc ですが、gVisor を使用する場合は runc になります。

gVisor を使用して Kubernetes で Linux ホストとコンテナを分離する

ここでは、Kubernetes クラスターに複数のコンテナランタイムを用意し、機密性の高いワークロードに対してより制限の厳しいコンテナランタイムを選択する方法について説明します。

このチュートリアルでは、containerd を使用して Kubernetes クラスターをインストールした以前のプロジェクトを使用しました。

https://github.com/alessandrolomanto/k8s-vanilla-containerd

Kubernetes クラスターを初期化します。

 vagrant の作成- 開始

マシンを起動した後、すべてのコンポーネントが起動して実行されていることを確認します。

 vagrant ssh マスター

kubectl ノードを取得する

 名前ステータス役割年齢バージョン

マスター準備完了コントロールプレーン、 マスター7 m59s v1 .21 .0

 ワーカー1 準備完了< なし> 5 分 50 秒v1 .21 .0

 ワーカー2 準備完了< なし> 3 m51s v1 .21 .0

worker1 に gVisor をインストールします。

 ssh worker1 # Vagrant のデフォルトパスワード: vagrant

 sudo su

最新の gVisor バージョンをインストールします。

 （
 セット- e
 ARCH = $ ( uname - m )
 URL = https://storage.googleapis.com/gvisor/releases/release/latest/${ARCH }
 wget $ { URL } /runsc ${URL}/ runsc 。 sha512 \\
 $ { URL } /containerd-shim- runsc - v1 $ { URL } /containerd-shim-runsc-v1.sha512
 sha512sum -c を実行します。 sha512 \\
 -c コンテナ- shim - runsc - v1.sha512
 rm -f * .sha512
 chmod a + rx runsc containerd - shim - runsc - v1
 sudo mv runsc containerd -shim - runsc -v1 / usr / local / bin
 ）

 終了しました-- 2022-04-28 07 : 24 : 44 --

 合計壁時計時間: 5.2 秒

ダウンロード: 4 ファイル、62M 、 3.1 秒( 20.2 MB / 秒)

 runsc : OK

 containerd - shim - runsc - v1 : OK

コンテナランタイムを構成します。

 猫<< EOF | sudo tee / etc / containerd / config を実行します。 トムル
バージョン= 2
 [ プラグイン. ["io.containerd.runtime.v1.linux" ]
 shim_debug = 真
[ プラグイン. 「io.containerd.grpc.v1.cri」 。 コンテナ化。 ランタイム。 ランク]
 runtime_type = "io.containerd.runc.v2"
 [ プラグイン. 「io.containerd.grpc.v1.cri」 。 コンテナ化。 ランタイム。 ランスc ]
 ランタイムタイプ= "io.containerd.runsc.v1"
 終了

コンテナサービスを再起動します。

 sudo systemctl コンテナを再起動します

gVisor の RuntimeClass をインストールします。

 猫<< EOF | kubectl を適用- f -
 apiバージョン: ノード。 k8s 。 io / v1beta1
 種類: ランタイムクラス
メタデータ:
 名前: gvisor
 ハンドラ: runsc
 終了

確認する：

 vagrant @ マスター: ~ $ kubectl ランタイムクラスを取得する

名前ハンドラー年齢

gvisor ランス17 秒

gVisor RuntimeClass を使用して Pod を作成します。

 猫<< EOF | kubectl を適用- f -
 APIバージョン: v1
 種類: ポッド
メタデータ:
 名前: nginx - gvisor
 仕様:
 ランタイムクラス名: gvisor
 コンテナ:
 - 名前: nginx
 画像: nginx
 終了

Pod が実行中であることを確認します。

 kubectl get pod nginx - gvisor - o ワイド

 vagrant @ マスター: ~ $ kubectl get pod nginx - gvisor - o wide

 名前準備完了ステータス再起動年齢IP ノード指名ノード準備完了ゲート

nginx - gvisor 1 / 1 実行中0 31 秒192.168 .235 .129 worker1 < なし> < なし>

最新情報については、公式ドキュメントを参照してください。 https://gvisor.dev/docs/user_guide/install/

結論は

現在のコンテナテクノロジでは、分離が弱いという問題が起こっていることがわかりました。コンテナの迅速なパッチ適用や最小限のセキュリティコンテキスト権限などの一般的なプラクティスにより、攻撃対象領域を効果的に制限できます。コンテナランタイムが複数存在する可能性があるため、上記のチュートリアルのようにランタイムセキュリティ対策の実装を開始する必要があります。

もちろん、これは誰もが必要とするものではありませんが、ホストマシンに何ら影響を与えずに信頼できないコンテナを実行したい場合には確かに便利です。

同じホスト上で異なる顧客のコンテナを起動するコンテナホスティングサービスであるとします。コンテキストを共有することで他のクライアントに害を与えていませんか?これらの問題を軽減する方法について考え始めましょう。

<<: クラウドコストの最適化に関するベストプラクティスは何ですか?

>>: プラットフォーム・アズ・コードの未来はKubernetes拡張機能