コンテナ化の原則について話しましょう

コンテナ化

LXC であれ Docker であれ、基盤となるコア テクノロジーは Cgroups と Namespace です。 cgroups は、プロセス リソースの使用を制限するために Linux カーネルによって提供されるテクノロジーです。 CPU、メモリ、ディスク、ネットワーク I/O など、プロセスで使用される物理リソースを制限および分離できます。物理的なリソースの分離と比較して、名前空間は、Java のクラスローダーと同様に、プロセス ID やネットワークなどのシステム リソースを分離するために使用されます。同じ PID と IP であっても、異なる名前空間は互いに独立しており、互いに影響を与えません。たとえば、親コンテナは clone() 関数を呼び出して、それぞれ ID 100 と 101 を持つ 2 つの子プロセスを作成します。 2 つの子プロセスにはそれぞれ独自の名前空間があります。子プロセスにマッピングされた後、それらはそれぞれ PID 1 の init プロセスに対応します。両方の名前空間の PID は 1 ですが、図に示すように、名前空間は分離されており、2 つは互いに影響を及ぼしません。

写真

分離により、サブコンテナは互いに干渉することなく比較的独立して動作できます。各コンテナは特定のタスクを処理するように設計されています。たとえば、一部のコンテナはデータベース サービスを提供する役割を担い、一部のコンテナはキャッシュ サービスを提供する役割を担い、一部のコンテナはアプリケーション システムの操作を担当します。コンテナの作成後に何を行うかをどのように決定しますか?答えは Dockerfile にあります。

Dockerfile は、コンテナが実行するサブプロセスを記録し、コンテナのコア機能を決定する人体の DNA に例えられます。 Dockerfile を使用すると、イメージを構築し、いつでも複数のコンテナを起動して、アプリケーションの迅速な拡張を実現できます。ビジネス アプリケーションのイメージは本質的に非常に似ています。アプリケーション A の Dockerfile が DockerfileA であり、アプリケーション B の Dockerfile が DockerfileB であると仮定します。どちらもオペレーティング システム、JDK、Tomcat、ログ コレクターなどに依存します。アプリケーションの War パッケージのみが異なります。各イメージが複数の共通部分を繰り返し維持する場合、結果として生じるリソースの損失とメンテナンス コストは膨大になります。

Docker は階層化テクノロジーを使用してこの問題を解決します。各コンテナには独自の独立したコンテナ レイヤーがあり、異なるコンテナがイメージ レイヤーを共有するため、コンテナ間で基本リソースを共有できます。ベース イメージ (通常はベース イメージと呼ばれます) をディスクに保存すると、図に示すように、他のイメージと共有できるようになります。

写真

Dockerfile の最下層で使用されるコア ファイル共有テクノロジは UFS です。 UFS は軽量で高性能な階層化ファイルシステムです。 UFS は、ファイル システムの各変更をレイヤーとして重ね合わせ、異なるディレクトリを同じ仮想ファイル システムにマウントできます。複数のファイル システムが同時にロードされる場合、UFS は各レイヤーでファイルをスタックし、最終的なファイル システムには基礎となるすべてのファイルとディレクトリが含まれます。外部の観点から見ると、ユーザーはファイル システムを参照します。画像はUFSの特性を活かして、レイヤー化により継承・重ね合わせています。通常は、まず基本イメージを作成し、その基本イメージからさまざまな特定のアプリケーション イメージを派生させます。 UFS は Docker イメージの基礎です。

このセクションでは、いくつかのコア仮想化およびコンテナ化テクノロジについて説明します。それらについて説明しましょう。

Cgroups (コントロール グループ)

cgroups は、プロセスによる CPU、メモリ、ディスク、ネットワーク帯域幅などのシステム リソースの使用を制限および分離するために Linux カーネルによって提供されるリソース管理メカニズムです。これにより、システム管理者はさまざまなプロセス グループにリソースを割り当て、各グループが使用できるリソースの量を制限できます。

Cgroups (コントロール グループ) は、Linux カーネルによって提供されるリソース管理メカニズムです。その原則は主に以下の側面に関係します。

リソースの分離

cgroups を使用すると、管理者はシステム内のプロセスを異なるグループに分割し、各グループに特定のリソース制限を割り当てることができます。これにより、各グループ内のプロセスは、他のグループのプロセスに影響を与えることなく、割り当てられたリソースのみを使用できるようになります。

リソース管理

Cgroups を使用すると、管理者は CPU、メモリ、ディスク、ネットワーク帯域幅などのリソース制限を各グループに設定できます。これらの制限は、ハード制限 (超過不可) またはソフト制限 (一定期間超過可能) に設定することができ、システム リソースを正確に制御および管理できます。

階層

Cgroups は階層構造をサポートしており、管理者は複数レベルの組織構造を作成できます。この階層構造により、リソース管理がより柔軟になり、必要に応じてさまざまなレベルのグループに対してさまざまなレベルのリソース割り当てと制限を実行できます。

制御インターフェース

Cgroups は、管理者がグループのリソース制限を動的に管理および調整できるようにする一連の制御インターフェースを提供します。これらのインターフェースはファイルシステムを介してアクセスおよび操作できるため、リソース管理がシンプルかつ柔軟になります。

要約すると、Cgroups の原理は、プロセスをグループ化し、リソース制限を設定することでシステム リソースを分離および制御し、それによってシステムがリソースを効果的に利用し、システムのパフォーマンスと安定性を向上させることです。

秘密の質問

cgroups 自体はセキュリティ上の問題を引き起こしません。これは、管理者がシステム リソースをより適切に管理および制御できるようにするために Linux カーネルによって提供されるリソース管理メカニズムであるためです。しかし、実際の使用においては、注意を払う必要がある潜在的な安全上の危険性がいくつかあります。

資源競争

Cgroup が適切に構成されていない場合、リソース競合の問題が発生し、一部のグループまたはプロセスが過剰なリソースを占有し、他のグループまたはプロセスが正常に動作しなくなります。したがって、リソースの過剰割り当てを避けるために、リソース制限を合理的に設定する必要があります。

権限の問題

Cgroup の構成と管理には、システムの権限管理が含まれます。権限が適切に設定されていない場合、権限のないユーザーがシステム リソースを制御できるようになり、セキュリティ上のリスクが生じる可能性があります。したがって、Cgroup へのアクセス権は厳密に管理および制御する必要があります。

DoS攻撃

攻撃者が Cgroups の制限を回避し、悪意を持ってシステム リソースを占有すると、システム リソースが枯渇し、システムの正常な動作に影響を及ぼします。そのため、DoS（サービス拒否）攻撃を防ぐためには、異常な動作を適時に監視し、対応する必要があります。

まとめると、Cgroups 自体はセキュリティ上の問題を引き起こすことはありませんが、リソースの競合、権限の問題、DoS 攻撃などのセキュリティ リスクを回避するために、使用中に適切な構成と管理に注意を払う必要があります。同時に、システムとカーネルのバージョンをタイムリーに更新して、既知のセキュリティの脆弱性を修正し、システムのセキュリティを強化します。

名前空間

名前空間は、プロセス ID (PID)、ネットワーク、ファイル システム、ユーザーなどのプロセスのグローバル リソースを分離するために Linux カーネルによって提供される分離メカニズムです。異なる名前空間によって仮想化環境が提供されるため、同じホスト上で実行されているプロセスは互いに分離され、干渉し合うことはありません。

名前空間は Linux カーネルによって提供される分離メカニズムであり、システム リソースを複数の独立した分離された環境に分割するために使用されます。これにより、同じホスト上で実行されているプロセスが異なるシステム リソースを参照できるようになり、リソースの分離と仮想化が実現します。 Linuxカーネルは、PID（プロセスID）、ネットワーク、マウント（ファイルシステムのマウントポイント）、IPC（プロセス間通信）、UTS（ホスト名とドメイン名）など、複数のタイプの名前空間を提供します。以下は、名前空間の主なタイプとその機能の一部です。

PID 名前空間

各 PID 名前空間には独自のプロセス ID 空間があり、その中のプロセス ID は他の名前空間からは見えません。これにより、異なる PID 名前空間で実行されているプロセスをそれぞれ独自のプロセス ツリーで分離できるため、プロセスの管理と制御が向上します。

ネットワーク名前空間

各ネットワーク名前空間には、ネットワーク デバイス、IP アドレス、ルーティング テーブル、ネットワーク接続などを含む独自のネットワーク スタックがあります。これにより、異なるネットワーク名前空間で実行されているプロセスが独立したネットワーク環境を持つことができ、ネットワークの分離と仮想化が実現されます。

マウント名前空間

各マウント名前空間には独自のファイル システム マウント ポイントがあるため、異なるマウント名前空間で異なるファイル システム ビューを使用できます。これにより、ファイル システムの分離が実現され、異なるプロセスに異なるファイル システム環境を持たせることができます。

IPC 名前空間

IPC 名前空間はプロセス間通信メカニズムの分離を提供し、異なる IPC 名前空間内のプロセスが直接通信することを不可能にし、システムのセキュリティと分離を強化します。

UTS 名前空間

UTS 名前空間はホスト名とドメイン名の分離を提供するため、異なる UTS 名前空間は異なるホスト名とドメイン名を持つことができ、それによってシステム識別情報の分離を実現します。

これらの名前空間を使用してコンテナを作成し、コンテナ間の分離と仮想化を実現できます。異なるタイプの名前空間を組み合わせることで、より柔軟で強力なコンテナ分離環境を実装し、より安全で信頼性の高いコンテナの動作環境を提供できます。

秘密の質問

名前空間自体にはセキュリティ上の問題はありません。これは、分離されたオペレーティング環境を作成するために Linux カーネルによって提供されるリソース分離メカニズムです。しかし、実際の使用においては、不適切な構成や抜け穴によりセキュリティ上の問題が発生する可能性があります。セキュリティ上の問題を引き起こす可能性がある状況は次のとおりです。

権限昇格の脆弱性

コンテナ内で実行されているプロセスに権限昇格の脆弱性がある場合、攻撃者はルート権限を取得し、コンテナからホストマシンに逃げることができます。

コンテナからの脱出

コンテナ自体に脆弱性がある場合、攻撃者はその脆弱性を悪用してコンテナから脱出し、ホスト上の機密情報を入手したり、ホストを制御したりする可能性があります。

不完全な名前空間分離

名前空間の分離が不完全であったり抜け穴があったりすると、情報漏洩やコンテナ間の相互影響が発生する可能性があります。

共有名前空間

コンテナが特定の名前空間を共有する場合、コンテナ間で情報が共有され、攻撃対象領域が拡大します。

コンテナ環境のセキュリティを確保するためには、次のような一連のセキュリティ対策を講じる必要があります。

• コンテナ イメージと基本的なオペレーティング システムをタイムリーに更新し、既知の脆弱性を修正します。
• コンテナの権限を制限し、最小権限の原則を使用します。
• SELinux、AppArmor などのセキュリティ ポリシーを有効にして、コンテナのシステム コールを制限します。
• コンテナ間の通信を制限するために、ネットワーク分離とセキュリティ グループ ポリシーを実装します。
• セキュリティ監査ツールを使用してコンテナ環境を監視および監査し、異常な動作をタイムリーに検出します。
• Docker のセキュリティ スキャン、コンテナ署名など、コンテナ ランタイムのセキュリティ機能を使用します。

まとめると、Namespace 自体はセキュリティ上の問題を引き起こすことはありませんが、コンテナ環境のセキュリティを確保するためには、実際の使用において構成と管理に注意を払う必要があります。

Dockerファイル

Dockerfile は、Docker イメージの内容とビルド手順を定義するテキスト ファイルです。 Dockerfile を使用すると、ベースイメージ、コンテナ内で実行するコマンドの指定、ファイルとディレクトリの追加、環境変数の設定などを行うことができます。Dockerfile を使用すると、カスタマイズされた Docker イメージを簡単に作成し、アプリケーションを簡単にデプロイおよび管理できます。

ユニオンファイルシステム (UFS)

階層化ファイル システムは、複数のファイル システムを同じ仮想ファイル システムにマウントして階層構造を形成できるファイル システム テクノロジです。 Docker では、各コンテナには独自のコンテナ レイヤーがあり、異なるコンテナが同じベース イメージ レイヤーを共有できます。この階層化メカニズムにより、ディスク領域を節約し、イメージの再利用性と展開効率を向上させることができます。

ユニオン ファイル システム (UFS) は、複数のファイル システム層を同じ仮想ファイル システムにマウントして階層構造を形成するファイル システム テクノロジです。 Docker では、コンテナ イメージの構築と管理に階層化ファイル システムの概念が広く使用されています。

階層化ファイル システムの主な原則は、ファイル システムのレイヤー オーバーレイ機能を活用することです。各ファイル システム レイヤーにはファイルとディレクトリを含めることができ、他のファイル システム レイヤーによってオーバーレイできます。 Docker では、各コンテナは、読み取り専用のベース イメージ レイヤーと読み取り/書き込みコンテナ レイヤーを含む複数のファイル システム レイヤーで構成されます。これらの階層構造を組み合わせることで、コンテナをビルディングブロックのように組み立てることができ、同じファイルを繰り返し保存することなく、必要に応じてさまざまなイメージを組み立てることができます。

具体的には、階層型ファイルシステムは次のように動作します。

ベースイメージレイヤー

ベース イメージ レイヤーには、コンテナーの基本ファイル システムが含まれており、通常はオペレーティング システムのコア ファイルとシステム ツールが含まれます。このレイヤーは読み取り専用であり、すべてのコンテナーは同じベース イメージ レイヤーを共有します。ベースイメージレイヤーは通常、Docker Hub またはプライベートリポジトリによって提供され、開発者によって保守および更新されます。

コンテナレイヤー

各コンテナには独自のコンテナ レイヤーがあり、アプリケーション、構成ファイル、ログなど、コンテナ固有のファイルとディレクトリを保存するために使用されます。コンテナ レイヤーは書き込み可能であり、コンテナの実行状態に基づいて変更できます。コンテナが起動すると、コンテナ レイヤーがベース イメージ レイヤーに重ね​​合わされ、コンテナの完全なファイル システムが形成されます。

コピーオンライト

コンテナがファイル システムに書き込む場合、階層化ファイル システムは Copy-on-Write 戦略を使用します。つまり、書き込み操作が発生すると、ファイル システムはベース イメージ レイヤー内のファイルを直接変更するのではなく、コンテナー レイヤー上にファイルの新しいコピーを作成します。これにより、ストレージスペースを最小限に抑えながら、各コンテナに独自の独立したファイルシステムが確保されます。

画像の組み立てと再利用

階層化ファイルシステムの特性により、異なるファイルシステムレイヤーを重ね合わせて Docker イメージを構築できます。これにより、画像をビルディングブロックのように柔軟に組み立てることができ、画像の再利用と共有が可能になります。複数のイメージが同じベースイメージレイヤーを共有する場合、異なるコンテナレイヤーのみを保存すればよく、ストレージスペースの消費量が大幅に削減されます。

要約すると、階層化ファイルシステムは Docker において非常に重要な概念です。ファイルシステムのレイヤーオーバーレイ特性を活用することで、イメージの効率的な構築、展開、管理を実現します。コピーオンライトとイメージの再利用により、階層化ファイルシステムはストレージスペースを節約し、コンテナのパフォーマンスと効率を向上させることができます。

秘密の質問

階層化ファイルシステムは Docker に多くの利点をもたらしますが、セキュリティ上の考慮事項もいくつかあります。

コンテナからの脱出

コンテナは階層化されたファイルシステムによって分離されていますが、場合によっては、悪意のあるユーザーがオペレーティングシステムまたは Docker エンジンの脆弱性を悪用してコンテナから脱出し、ホストシステムの権限を取得できる可能性があります。このコンテナ エスケープ攻撃により、ホスト システムが侵害されたり破壊されたりします。

イメージ汚染

ベースイメージレイヤーまたはその他の共有レイヤーに脆弱性または悪意のあるコードがある場合、それらのイメージ上に構築されたすべてのコンテナーが影響を受けます。攻撃者は、イメージ ファイルを変更または改ざんすることでマルウェアやバックドアを挿入し、コンテナー内のアプリケーションとデータのセキュリティを侵害する可能性があります。

安全でないベースイメージ

安全でない、または検証されていないベースイメージを使用すると、コンテナ上に構築された階層化ファイル システム全体が危険にさらされます。公式または信頼できるベースイメージを使用し、既知の脆弱性やセキュリティ問題にパッチを適用するためにタイムリーに更新することをお勧めします。

ファイルシステムの権限

コンテナ内では、ファイル システムのアクセス許可は通常、コンテナのランタイム構成とユーザー設定によって決まります。ファイル システムのアクセス許可が正しく構成されていない場合、コンテナー内の機密ファイルが権限のないユーザーによってアクセスまたは変更され、データの漏洩や破損が発生する可能性があります。

これらのセキュリティ リスクを軽減するには、次の対策が推奨されます。

• 公式または信頼できるベースイメージを使用し、定期的に更新して最新のセキュリティ パッチと修正プログラムを入手してください。
• コンテナ ランタイムの安全な構成の使用、コンテナへの特権アクセスの制限、不要なシステム コールの無効化などのセキュリティのベスト プラクティスを実装します。
• コンテナのアクセス制御ポリシーを構成して、コンテナ間の通信とリソース アクセスを制限し、コンテナが必要な最小限の権限リソースにのみアクセスできるようにします。
• コンテナの実行状態と動作を監視し、セキュリティの脅威や攻撃を迅速に検出して対応します。

まとめると、階層化ファイルシステムはコンテナ化されたアプリケーションに利便性と効率性をもたらしますが、実際のアプリケーションではセキュリティリスクに注意を払い、リスクを防止および対応するための適切な対策を講じる必要があります。

これらの技術がコンテナ化技術の中核を構成し、コンテナがリソースの分離、軽量、迅速な展開という特性を実現できるようになります。

機能関係図

Plantumlを使用して、3つの関係の図を次のように描きます。

 @startuml left to right direction skinparam packageStyle rectangle skinparam padding 10 skinparam defaultFontName Helvetica package "Host" { package "Namespace" { [Process 1] as Process1 [Process 2] as Process2 [Process 3] as Process3 } package "Cgroup" { [Cgroup 1] as Cgroup1 [Cgroup 2] as Cgroup2 [Cgroup 3] as Cgroup3 } package "UnionFS" { [Layer 1] as Layer1 [Layer 2] as Layer2 [Layer 3] as Layer3 } Process1 --> Cgroup1 Process2 --> Cgroup2 Process3 --> Cgroup3 Cgroup1 --> Layer1 Cgroup2 --> Layer2 Cgroup3 --> Layer3 } @enduml

写真

この図は、ホスト上の 3 つの主要なテクノロジー (Namespace、Cgroup、UnionFS) 間の関係を示しています。

• 名前空間は、プロセス ID (PID)、ネットワーク、ファイル システムなどのプロセスのグローバル リソースを分離するために使用されます。図では、各プロセスに独自の名前空間が割り当てられ、プロセス間の分離が保証されています。
• Cgroup は、CPU、メモリなどのプロセスによるシステム リソースの使用を制御および制限するために使用されます。各プロセスは対応する Cgroup に割り当てられ、リソースへのアクセスが制限されます。
• UnionFS を使用すると、複数のファイル システムを同じ仮想ファイル システムにマウントして階層構造を形成できます。各 Cgroup は、プロセスに必要なファイル システム コンテンツを含む 1 つ以上の階層型ファイル システム レイヤーに関連付けられます。

要約すると、名前空間は分離された実行環境を提供し、Cgroup はリソースの使用を制御し、階層型ファイル システムはファイル システム階層を提供し、コンテナーがファイル システムの内容を共有および再利用できるようにします。