containerdとは？ Dockerとの比較
Dockerは開発者に選ばれる手法で、ソフトウェアやコンテナ化されたアプリを提供するのに役立ちます。Dockerはコンテナがなければ動作しません。また、containerdがコンテナのライフサイクルを管理するため、Dockerの動作にとっても重要です。これら3つは密接に関連しているため、Docker利用者は各々を正しく理解する必要があります。
本記事ではcontainerdに注目し、その意味、役割、そしてDockerやコンテナにとっての重要性を解説します。
成長戦略の一環として、DockerはコンテナランタイムのリソースであるContainerdをリリースし、CNCFに寄付して開発者コミュニティに提供しました。
Dockerとその歴史
PaaSソリューションとして提供されるDockerは、2013年に開発者がコンテナの構築と運用に利用するためのオールインワンのリソースとして登場しました。主な役割は、OSレベルの仮想化を用いてコンテナを稼働させることでした。
初回リリース後、2014年に初のバージョンが公開されました。しかし、Dockerデーモンの影響でセキュリティに問題があり、利用者から不満が出たと報じられています。
Dockerを用いたクラウド上でのコンテナ管理も大きな課題でした。代替策として、熟練のGoogle開発者数名が生み出したKubernetesが登場し、K8sは多数のマシンネットワークにおけるコンテナの運用を簡素化しました。
KubernetesもDockerコンテナとの連携が必要で、正常なコンテナに依存していました。その後、Dockerにいくつかの改良が加えられ、たとえばKubernetesの使い勝手を改善するためにDockershimが導入されました。さらに、Swarmが登場し、Kubernetesの代替としてコンテナ管理が可能になりました。
市場での普及と需要の高まりを受け、Dockerは柔軟な導入を求める企業向けにDocker Enterprise Edition (EE)をリリースしました。成長戦略の一環として、DockerはコンテナランタイムのリソースであるContainerdをリリースし、CNCFに寄付して開発者コミュニティに提供しました。
containerdとは？
まず、Dockerによりコンテナランタイムとして開発され、仮想環境や物理環境におけるコンテナのライフサイクル管理を担っています。コンテナの作成、起動・停止など全ての動作を管理します。
その機能は以下にまで及びます:
- 各種レジストリから必要なコンテナイメージを取得する
- 需要に応じてコンテナストレージをマウントする
- 各コンテナへネットワーク効率を付加する
前述の通り、containerdはCNCFに組み込まれ、CoreDNSやEnvoyなどと肩を並べる存在となりました。
containerdの登場は、k8sにとってDockerの重要な低レベル要素を管理する大きな転機となりました。k8sでcontainerdを利用すれば、コンテナランタイムとしてDockerを必要としません。
ContainerdとDockerの違い
Dockerとcontainerdは密接に関連しているため、混乱する場合があります。ここで整理します。
- Dockerはコンテナ実行・管理の手段で、必要な技術支援やリソースを提供します。
- ContainerdはDocker由来のコンテナランタイムですが、単独でも利用できます。
Containerdの役割
Kubernetesなどにおいて、containerdは複数のLinuxカーネル機能を簡潔に抽象化したものに過ぎません。
コンテナリソースとして低レベルの接続層に位置し、クライアント層として機能するため、コンテナソフトがその上で構築できます。
この利用によりKubernetesの運用が簡素化されました。当初、Kubernetes開発は、Dockerのインターフェース周辺に常にshimを書くか、Linuxカーネル機能と直接連携するかの2通りに頼っていました。
いずれの方法も複雑で手間がかかるため、Dockerがcontainerdを分離したことで、システム抽象化層上でcontainerd shimを利用する新たなk8s開発手法が生まれ、Dockerの関与を極力抑えることができました。
OCI
Open Container Initiativeの略であるOCIは、コンテナの基準を定義し、その見た目や動作を決める管理組織です。世界的に認められた仕様は、コンテナの効率的な動作のための高度なインターフェースを提供します。
ContainerdはOCIの仕様に厳格に従っているため、主にOCIに準拠しています。OCIの主要な目的はコンテナ利用の支援であり、各プラットフォームでイメージが矛盾なく利用できるようにしています。
Containerd と CRI、CRI-O、RUNC の比較
Containerdだけが気になるコンテナ要素ではありません。他にも密接に関連する要素があります。次に、いくつかの主要なコンテナ用語を比較します。
CRI-O: containerdと同様にコンテナランタイムですが、複雑なLinux機能を持たないため、攻撃対象が狭まります。また、containerdはOSレベルに基づいていますが、CRI-OはCRIのOCI準拠実装です。
CRI または Container Runtime Interface: これはAPIとして、k8sがコンテナランタイムを完全に制御するのに役立ちます。containerd CRIは、Kubernetesが全てのランタイムと連携するための仕組みです。Containerdとは異なり、CRIは真のコンテナランタイムとして機能するために追加サポートが必要です。
Runc: containerdが高レベルのランタイムであるのに対し、Runcは低レベルで動作し、ネームスペース管理やLinuxカーネルとの連携など、基本的な機能を提供します。
containerdの機能
- クライアントがcontainerdを希望の環境に展開します。このライブラリはクラウド上でもローカルでも動作します。
- 各ホスト上のコンテナグループを分離するためにネームスペースを利用し、名前の重複と混乱を防ぎます。
- Containersは最も重要な機能で、ファイルシステム、コンテナイメージ、OCIランタイムなどと連携して処理を行うためのメタデータオブジェクトです。
- containerdの機能拡張として、スナップショットプラグイン機能はGRPCを利用し、外部プラグインを追加できます。
- OCIランタイム仕様機能は、各コンテナランタイムが従うべき標準化された動作を実現します。
containerdのセキュリティ推奨事項
クラウド展開の増加に伴いリスクも増大しています。コンテナの利用はクラウド環境のセキュリティ複雑性を高めました。K8sでcontainerdを使用する場合は、より賢明なセキュリティ対策が求められます。
containerdはSSHやCLIを使用しなくとも、socketファイルへの不正アクセスにより制御が奪われる恐れがあるため、高いセキュリティリスクを伴います。その上、脅威者がnerdctlやcrictlなどを容易にダウンロードできる可能性があります。
containerdは以下の理由により攻撃対象が広がります:
- Linux機能
- Docker Engineの利用（例：保護されていないコンテナイメージに悪意ある要素が含まれていたり、ハードコードされた秘密情報が漏れる恐れがある）
幸いにも、containerdの攻撃対象を狭める方法があります。最適な選択肢を見てみましょう。
- コンテナをrootで実行しない
- containerdの権限を最低限に抑える
- 使用前にイメージをスキャンする
- 使用前にイメージのセキュリティと整合性を確認する
- セキュリティ強化済みのコンテナイメージを使用する
- イメージの秘密情報を暗号化なしの状態にしない
- セキュリティの脆弱性を防ぐため、containerdのバージョンを常に更新する
結論
containerdにより、Dockerの機能がシンプルになり、Kubernetesやコンテナの運用が促進されました。しかし、攻撃対象が広いため、利用者は適切な対策を学ぶ必要があります。イメージの秘密情報確認やcontainerdの更新など、紹介した対策は大いに有用です。
FAQ
最新情報を購読
.jpeg)
