- コンテナはホストとカーネルを共有するため、その分離は名前空間、cgroup、およびシステム強化に依存します。
- Podman は、中央のルートデーモンを回避し、ルートレス実行を容易にすることで、従来の Docker に比べてセキュリティを強化します。
- Podman のブリッジ、ホスト、およびルートレス ネットワーク (slirp4netns、paste) を使用すると、接続性と分離性のバランスを調整できます。
- KVM、コンテナ、ベストプラクティス（ルートレス、MAC、seccomp、イメージスキャン）を組み合わせることで、本番環境向けの堅牢なプラットフォームが実現します。
Linux上で本格的なコンテナ環境を構築し始めると、すぐに同じ疑問が生じます。コンテナのみに頼ることはどの程度安全なのか、そしてKVMやマイクロVMにアップグレードすべきタイミングはいつなのか、ということです。Docker、Podman、LXC、KVM仮想マシン、そして様々なハイパーバイザーが混在する企業環境では、分離モデルをしっかりと理解することが、ミスを避けるための鍵となります。
さらに、 VirtualBoxやKVMの仮想マシン内でDocker DesktopやPodmanを使用しようとするなど、やや複雑なシナリオも珍しくありません。このようなシナリオでは、複数のレベルの仮想化（ネストされているか否かを問わず）が関係し、「ホスト上でKVMが有効になっていません」といったエラーが発生しやすくなります。そこで、コンテナ、VM、Podman、KVM、ネットワーク、セキュリティといった要素を整理し、それらを組み合わせて真に安全で実用的な仮想化を実現する方法を見ていきましょう。
KVMと仮想マシンによる従来の仮想化
このシステム全体の基盤となるのは、KVM、Xen、ESXiなどのハイパーバイザーを用いたオペレーティングシステムの完全仮想化です。ここでは、物理ハードウェア上でハイパーバイザーが実行され、そのハイパーバイザーがマシンを複数の独立した仮想マシンに「分割」する役割を担います。
このモデルでは、各仮想マシンはホストとは完全に独立した独自のカーネルとゲストオペレーティングシステムを起動します。ハイパーバイザ（例えば、Linuxカーネルに統合されているKVM）は、ハードウェアと仮想マシンの間のゲートキーパーとして機能し、両者間の強力な分離を担います。
ハイパーバイザーには一般的に2種類あります。ハードウェア上で直接動作するタイプ1（ベアメタル）ハイパーバイザーと、既存のオペレーティングシステム上で動作するタイプ2ハイパーバイザーです。VirtualBoxやVMware Workstationはタイプ2に該当し、Linuxサーバー上でlibvirtによって管理されるKVMは、ホスト自体とスペースを共有しているとはいえ、タイプ1に近いと言えます。
このアプローチの最大の利点は、各仮想マシンがカーネル、ユーザー空間、サービス、ネットワーク、ストレージといった完全なスタックを独自に持つことです。これにより、高い柔軟性が得られ、同じ物理マシン上で異なるオペレーティングシステムやカーネルバージョンを実行することが可能になります。
GNU/Linux でこれらの仮想化プラットフォームを管理するために、オーケストレーション API としてlibvirt がほぼ常に使用され、その上にグラフィカルツールやコマンドラインツールがサポートされます。また、VM、ベアメタル、コンテナを組み合わせて完全なクラウドを構築する OpenStack のような大規模なプロジェクトも存在します。
KVMのハードウェア要件とよくある問題
KVM を実行したり、KVM に依存するソリューション (一部の Docker Desktop やマイクロ VM 構成など) を使用する前に、プロセッサがハードウェア仮想化 (Intel の場合は VT-x、AMD の場合は SVM/AMD-V) をサポートしていること、およびBIOS/UEFI でそれが有効になっていることを確認する必要があります。
Linuxでは、簡単なチェック方法があります。`grep -E 'svm|vmx' /proc/cpuinfo`コマンドが何も返さない場合、またはファームウェアでオプションが無効になっている場合は、KVMは動作しません。さらに、別のVM内でVMを実行するシナリオ（ネストされた仮想化）では、最上位のハイパーバイザがこれらの拡張機能をゲストに明示的に公開する必要があります。
何らかの問題が発生すると、典型的なメッセージが表示されます。例えば、VirtualBox 内の RHEL 9 で発生する悪名高い Docker Desktop のポップアップ「ホストで KVM が有効になっていません」などです。ここでの問題は、Docker や RHEL 自体にあるのではなく、VirtualBox VM が KVM を実行するために必要な仮想化拡張機能を受け取っていないことにあります。
`modprobe kvm`や`modprobe kvm_amd / kvm_intel`のようなコマンドを実行すると、エラーメッセージなしでカーネルモジュールがロードされるはずです。`dmesg` に何も関連情報が表示されない場合、または`lsmod | grep kvm`に `kvm` と `irqbypass` しか表示されず、CPU 固有のモジュールが見つからない場合は、ハードウェア仮想化がゲストシステムに公開されていないか、ファームウェアで無効になっている可能性が非常に高いです。
このような場合、ゲストOS内で利用可能なすべての機能が有効になっていても、VirtualBoxがネストされた仮想化に対応していないか、設定が誤っていると、KVMは動作しません。解決策としては、ホストハイパーバイザー（VirtualBox、VMwareなど）の設定を確認し、利用可能な場合はネストされた仮想化を有効にする必要があります。
コンテナ: オペレーティングシステムレベルでの軽量仮想化
従来の仮想マシンとは対照的に、コンテナは異なるアプローチを採用しています。コンテナはすべてのハードウェアをエミュレートするのではなく、ホストカーネルを再利用し、Linuxカーネル関数を使用してプロセスとリソースを分離します。
コンテナとは、基本的に名前空間とcgroupを使用してカプセル化されたプロセスの集合です。この「環境」内では、アプリケーションは独自のファイルシステム、ネットワークインターフェース、およびPIDを持つ独自のマシン上で実行されていると認識しますが、実際にはホストとカーネルを共有しています。
コンテナは、2つ目のカーネルや完全なハードウェアエミュレーションを必要としないため、ネイティブに近いパフォーマンスを提供します。オーバーヘッドは最小限で、名前空間のマウント、cgroupsによるリソースの制限、セキュリティポリシー（seccomp、AppArmor、SELinuxなど）の適用に必要な分だけです。
しかし、この設計には重大な結果が伴います。すべてのワークロードが同じ物理カーネルを共有するため、そのカーネルに深刻な脆弱性があると、そのノード上で実行されているすべてのコンテナにとって、突然潜在的な脱出経路となってしまう可能性があるのです。
そのため、コンテナの分離は仮想マシンのように「絶対的」ではないとよく言われるのです。もし誰かが重大なカーネルのバグを悪用することに成功すれば、名前空間は有効な障壁ではなくなり、コンテナとホスト間の境界が破られる可能性があります。
名前空間とcgroup: コンテナ分離の基礎
Linuxでは、コンテナの分離は主に2つの柱に基づいています。システムビューを分離するための名前空間と、リソースを制限および管理するためのcgroupです。
名前空間は、プロセスID、ネットワーク、マウントポイント、IPC、ホスト名（UTS）、ユーザーなどを分離します。これにより、プロセスは自身の名前空間に属するプロセス、ネットワークインターフェース、ファイルシステム、ホスト名のみを「認識」できるため、まるで別のシステム上で動作しているかのような感覚が得られます。
cgroupsを使用すると、コンテナが消費できるCPU、メモリ、ディスクI/O、プロセス数などを指定できます。これにより、制御不能な負荷がホスト全体に過負荷をかけることを防ぎ、チーム間やプロジェクト間でノードを共有する際に不可欠な機能となります。
しかし、名前空間とcgroupだけでは完全なセキュリティシステムにはならないことを理解することが重要です。これらはカーネルの脆弱性の悪用を防いだり、システムコールをフィルタリングしたり、きめ細かなアクセスポリシーを管理したりするものではありません。これらは基盤ではありますが、強化する必要があります。
環境を強化する賢明な方法は、システムコールフィルタとseccomp、MACポリシー（AppArmorまたはSELinux）、およびプロセス機能の大幅な削減を組み合わせることです。理想的には、ユーザーネームスペースとルートレスモードを併用することで、誰かがコンテナから脱出できた場合の被害を最小限に抑えることができます。
コンテナプラットフォームにおけるセキュリティの脅威
実際のコンテナプラットフォームでは、攻撃対象領域は複数のレイヤーに分散しています。カーネルとランタイム（runc、containerd、CRI-O）、イメージサプライチェーン、コンテナ／オーケストレーター構成、そして基盤となるインフラストラクチャ（クラウド、ストレージ、IAM、ネットワーク）などです。
一般的な攻撃経路としては、カーネルやコンテナランタイムにおけるソフトウェアの脆弱性、安全性の低いイメージやメンテナンスされていないイメージの使用、KubernetesやDockerにおける設定ミス（特権コンテナ、危険なホストマウント、過度にオープンなネットワークモードなど）、レジストリやCI/CDパイプラインにおけるセキュリティ上の欠陥などが挙げられます。
多くの実際の事例では、単一の「魔法のバグ」は存在せず、既知の脆弱性とずさんな設定の組み合わせが原因です。例えば、root権限で実行されるコンテナ、--privilegedフラグの使用、コンテナ内でのホストファイルシステムのマウント、seccompやMACの欠如などが挙げられます。
さらに、サプライチェーンの問題も加わります。公開されているベースイメージには、CVE（共通脆弱性識別子）、古いパッケージ、管理が不十分な依存関係が含まれていることがよくあります。そのため、マルウェアがすり抜けたり、侵害されたライブラリが実行に適した条件が整うまで潜伏したりすることが比較的容易です。
したがって、本番環境ではこれは必須事項です。Trivy 、Clair、Grypeなどのツールを使用してイメージの脆弱性をスキャンし、使用するレジストリ（Harbor、Quay、ポリシー付きのGHCRなど）を制御し、クラスターにデプロイする前にイメージに署名/検証を行う必要があります。
Docker vs Podman: 脅威モデルへの影響
アプリケーションコンテナの世界では、DockerとPodmanは似たような機能を提供しますが、そのアーキテクチャは大きく異なり、ホスト上で扱うセキュリティモデルも変わってきます。
Dockerは、従来のrootfulモードでは、root権限で実行される中央デーモン（dockerd）に依存しています。CLIはこのデーモンと/var/run/docker.sockまたはTCP経由で通信し、コンテナの作成と削除、イメージ、ネットワーク、ボリュームの管理、レジストリとのやり取りは、この特権プロセスによって行われます。
これは、Dockerソケットにアクセスできるユーザーは、実質的にホストへのrootアクセス権を持っていることを意味します。なぜなら、特権コンテナを起動したり、任意のファイルシステムをマウントしたり、重要な設定を変更したりできるからです。結果として、デーモンは単一障害点となってしまいます。
一方、Podmanは、可能な限りLinuxに「ネイティブ」な、デーモン不要のコンテナエンジンというコンセプトのもとに誕生しました。常駐の中央プロセスは存在せず、コンテナはユーザーまたはsystemdによって制御されます。systemdとの統合により、サービスユニットを介してコンテナを制御することも可能になります。
このアプローチは、「各プロセスはそれを起動したユーザーに属する」というUnixモデルにより合致しており、高権限のデーモンに依存する必要がありません。さらに、PodmanはDockerコマンドとの互換性を提供し、移行を簡素化します（Docker CEをインストールしたくない環境では、`docker=podman`をエイリアスとして設定することも可能です）。
ルートレスモードとユーザー名前空間
コンテナのエスケープによる影響を軽減するための主要な実用的進歩の1つは、ルートレスモードとユーザーネームスペースの組み合わせです。この技術が解決しようとする疑問は、「コンテナがエスケープした場合、何が起こるのか？」です。
ユーザーネームスペースを使用すると、コンテナのUID 0をホスト上の非特権UIDに再マッピングできます。つまり、コンテナ内ではアプリケーションはroot権限を持っていると認識しますが、ホストの視点から見ると、そのプロセスは実際には割り当てられたsubuid/subgid範囲を持つ通常のユーザーです。
このように、攻撃者がコンテナ内でルート権限を取得し、カーネルまたはランタイムの脆弱性を悪用することに成功したとしても、ホストに戻る際には権限のないユーザーとして行動することになります。そのため、ルートバイナリを上書きしたり、機密性の高いファイルシステムをマウントしたり、必要な権限がないデバイスを操作したりすることはできません。
Podmanは、可能な限りデフォルトでルートレスコンテナ化を採用し、ルート権限がなくてもSELinux/AppArmorとcgroupsを使用し、構造的な権限を最小限に抑えることを重視するというモデルを念頭に置いて、当初から設計されました。
Dockerは、真のルートレスモードも提供するようになりました。このモードでは、dockerdとコンテナはユーザー名前空間内に配置されます。これは、デーモンがroot権限を保持していた従来のuserns-remapとは異なります。セキュリティの観点から、これによりdockerdに対する脆弱性を悪用してホストへの自動的なrootアクセス権限が付与されることを防ぎます。
Podman を使用したコンテナ ネットワーク: ブリッジ、ホスト、macvlan、ルートレス インターフェース
セキュリティと実用運用においてもう一つ重要な要素となるのが、コンテナネットワーク層です。Podmanは、特にルートレス環境を重視しながら、接続性を提供するための様々なメカニズムを提供しています。
Podman 4 では、CNI モデルに従ってコンテナにブリッジ ネットワーク、macvlan などの IP アドレスを提供するネットワーク ドライバである netavark が導入されました。netavark を使用すると、root 権限を持つコンテナは通常、デフォルトでホスト上の Linux ブリッジ (podman0) に関連付けられた「podman」というネットワークに接続し、アドレスは 10.88.0.0/16 になります。
このデフォルトのブリッジネットワークは、SNATルールを介して基本的なインターネット接続を提供し、`-po --publish`オプションを使用してコンテナポートをホストに公開できます。このオプションはiptables/nftablesにDNATルールを生成します。Dockerとの互換性を確保するため、このネットワークでは内部DNSサーバーは実行されません。
また、ユーザー定義のブリッジネットワークを作成することもできます。これにより、コンテナのグループを相互に分離し、内部DNSを提供できます。コンテナはプライベートネットワーク内で名前解決できるようになり、互いに通信できないようにすべきサービスを分離しやすくなり、MTU、ファイアウォール、その他の機能に対する制御性が向上します。
より高度な環境では、 macvlanまたはipvlanネットワークを使用して、コンテナをホストの物理ネットワークに直接接続することが可能です。macvlanはコンテナ同士の通信を可能にする一方、ipvlanはコンテナをより分離する傾向があります。これらは、各コンテナがネットワークの他の部分から実際のホストとして認識される必要があるデプロイメントにおいて有用なオプションです。
ルートレスネットワーク: slirp4netns と pasta
ユーザーがroot権限を持っていない場合、事態は複雑になります。権限のないユーザーはグローバルネットワークの名前空間を自由に変更したり、任意のインターフェースを作成したりすることができないため、Podmanは接続性を提供するためにユーザー空間のソリューションに頼らざるを得ません。
ここで登場するのが、Podman rootlessでよく使われる定番の仕組みであるslirp4netnsです。このプロジェクトはコンテナ内に隔離されたネットワーク環境を作成し、カーネルのslirpモジュールを使用してアドレス変換（NAT）を実行し、コンテナがホストのネットワーク経由でインターネットにアクセスできるようにします。
実際には、slirp4netnsはコンテナのネットワーク名前空間内にTAPインターフェース（例えば、IPアドレス10.0.2.100、ゲートウェイ10.0.2.2のtap0）を作成し、ユーザー空間で実装されたTCP/IPスタックを介してトラフィックをルーティングします。これは機能的には問題ありませんが、オーバーヘッドといくつかの制限が生じます。
これらの制限の1つとして、特権を持たないユーザーは1024未満のポートを使用できません。sysctlパラメータnet.ipv4.ip_unprivileged_port_startは、どのポートから「特権なし」とみなされるかを示します（デフォルトでは1024）。ただし、セキュリティモデルで許可されている場合は、これを慎重に調整できます。
Podman 5では、デフォルトのルートレスメカニズムとしてslirp4netnsの代わりにpastaが採用されました。Pastaも完全にユーザー空間で動作しますが、tapインターフェースとゼロコピー技術のおかげで、slirp4netnsと比較してレイテンシとスループットへの影響を軽減し、ネイティブネットワークに近いパフォーマンスを実現しています。
ルートレスコンテナ内のブリッジネットワークとホストネットワーク
非ルートモードで作業している場合でも、 `--network=podman` を使用することで、ルートレスコンテナをデフォルトの「podman」ブリッジネットワークに接続できます。これは、ルートモードと同様に、netavarkの機能を活用し、`-p` を使用してポートをホストにマッピングします。
ルートレス環境では、ユーザー定義のブリッジネットワークを作成することも可能です。この場合、ブリッジおよび関連デバイスはホストのグローバルネットワーク名前空間ではなく、ユーザーの名前空間に作成されるため、これらのインターフェースは単純な`sudo ip a`コマンドではホストから見えません。
これらのルートレスブリッジを検査するために、Podmanは`podman unshare --rootless-netns`コマンドを提供しています。このコマンドは、ユーザーのネットワーク名前空間でシェルを開きます。そこから、内部ブリッジを監視し、コンテナへの直接接続を確認できます。
この隔離には興味深い効果があります。 ホストからこれらのルートレス コンテナの IP への直接接続がない可能性があります。ただし、サービスへのエントリ ポイントとして機能する、ホスト独自の IP アドレスにマップされたポートでは機能します。
コンテナ間の通信では、ユーザー定義のブリッジ ネットワークに統合された DNS サーバーにより名前による通信が可能になり、分散アプリケーションの構成が大幅に簡素化されます。
もう一方の端はホストネットワーク（--network=host）で、コンテナは独自のIPアドレスを持たずにホストとネットワークスタックを共有します。このモードでは、ルートレスコンテナがポート8080/tcpでサーバーを起動すると、サービスはホストのポート8080で直接利用可能になり、ポートマッピングは不要になりますが、分離性は低下します。
Podmanデスクトップ、イメージングツール、ローカルオーケストレーション
より視覚的な操作を好むユーザー向けに、Podman Desktopは開発マシン上でコンテナ、ポッド、イメージ、ネットワーク構成を管理するためのグラフィカル環境を提供します。これはDocker Desktopの直接的な代替手段となりますが、デーモンレスエンジンに依存しています。
イメージは`podman pull`コマンドを使用して取得され、`/etc/containers/registries.conf`で定義されたレジストリからダウンロードされます。レジストリ名を指定せずにイメージを指定した場合、Podmanはデフォルトで`latest`タグを使用して、設定されたレジストリ順序内でイメージを検索します。
Podman CLIに加えて、skopeoを専用ツールとして使用することで、レジストリとローカルリポジトリ間でイメージを管理、検査、コピーできます。copy、delete、syncなどのコマンドを使用すると、リポジトリ間の同期を自動化したり、イメージをガベージコレクションの対象としてマークしたり、環境間でアーティファクトを移動したりできます。
イメージのダウンロードが完了したら、`podman run`コマンドを使用して、トランスポートとパスを指定することでコンテナを起動できます（デフォルトでは、Dockerトランスポートが使用され、設定済みのレジストリ内を検索します）。一般的なオプション（-d、-p、--name、--podなど）は、ラボ環境から本格的なデプロイメントまで幅広く対応しています。
日常的な管理は、コンテナの一覧表示には`podman ps`、既存のインスタンスの停止または起動には`podman stop/start`、停止中のコンテナの削除には`podman rm`を使用します。コンテナが変更され、それを新しいイメージに変換したい場合は、`podman commit`で変更内容を新しい名前で保存します。
PodとPodmanによる高度な実行モデル
Kubernetesにヒントを得たPodmanは、同じネットワークスタックと特定のリソースを共有するコンテナをPodにグループ化することを可能にします。データベースとそのクライアント、あるいは低遅延で通信する必要のある複数のマイクロサービスなどにとって、これは最適なパターンです。
コマンド`podman pod create` は新しいポッドを作成し、その ID を返しますが、デフォルトでは、関連付けられたコンテナが起動されるか、`podman pod start` で明示的に起動されるまで、ポッドは停止したままになります。
システム上にどのポッドが存在するかを確認するには、`podman pod ls`コマンドを使用します。このコマンドは、各ポッドに関連付けられている INFRA コンテナも一覧表示します。この特別なコンテナは、ポッドのネットワークやその他の共有リソースを稼働させ続けるため、コンテナの数はゼロになることはありません。
Podmanには、Pod全体を開始、停止、または再起動するための特定のコマンド（podman pod start/stop/restart）が用意されていますが、Pod内の他のコンテナを変更せずに特定のコンテナのみを操作することもでき、アプリケーションレベルでのプロセス分離を維持できます。
既存のポッドにコンテナを追加するには、個々のコンテナの場合と同じ構文で`podman run --pod POD_NAME`を使用します。ポッドのメンバーシップはライフサイクルに紐づいているため、コンテナを削除せずにポッドからコンテナを取り外すことはできません。
監視は、podman ps –pod または特定のコマンドを使用して、すべてのポッド内のすべてのコンテナのプロセスを監視し、どのコンテナがどのグループに属しているか、サービスがどのように分散されているかを迅速に特定することで完了します。
コンテナ、LXC、アプリケーション仮想化
DockerとPodmanが話題の中心となっているものの、GNU/Linuxにおけるコンテナ化の選択肢はこれらだけではありません。LXC/LXD、systemd-nspawn、Kata Containersといったソリューションは、それぞれ異なるアプローチでこの問題に取り組んでいます。
LXCは、独自のホスト名、IPアドレス、ファイルシステム、および完全なinitシステムを備えた、非常に軽量なシステムコンテナを提供します。コンテナと仮想マシンのハイパーバイザーとして機能するLXDと組み合わせることで、ベアメタルに近いパフォーマンスで、複数の軽量マシンを使用しているかのような体験を実現します。
Docker/PodmanはOCI準拠のアプリケーションコンテナに重点を置いているのに対し、LXCは複数のサービスやプロセスを持つ永続的な環境が必要な場合に真価を発揮します。仮想マシンのように動作しますが、オーバーヘッドが少なく、Linuxカーネルとの統合も非常に自然です。
パフォーマンスの観点から見ると、LXCはデータ集約型のエンタープライズアプリケーションをほぼペナルティなしで実行できるため、従来の仮想マシンのような強力な分離を必要としない、レイテンシに敏感なワークロードにとって強力な選択肢となります。
これに加えて、マイクロVMや高度な分離を目的とした技術も注目を集めている。例えば、各ポッドを独自のカーネルを持つ小型仮想マシン内で起動するKata Containersや、アプリケーションとLinuxの間にGo言語で書かれた「カーネルサンドボックス」を挿入するgVisorなどが挙げられる。どちらも共有カーネルへの依存度を低減し、コンテナの使いやすさを維持しながら、VMのセキュリティモデルに近づける。
DockerとPodmanを強化するためのベストプラクティス
上記すべてを踏まえると、堅牢なコンテナプラットフォームへの合理的なアプローチは、レイヤーごとに作業することです。名前空間/cgroupsによるセグメンテーション、seccompとMACによるフィルタリングポリシー、ルートレスモードによる構造的な特権制限などです。
実際には、特にマルチテナント環境や共有クラウド環境では、可能な限りコンテナを非ルートモードで実行するという標準的な方法を採用することをお勧めします。Podmanはデフォルトでこれを容易に実現し、互換性が必要な場合はDocker rootlessも同様の考え方に基づいています。
ホストカーネルは、セキュリティパッチを適用して常に最新の状態に保たなければなりません。ダーティCOW、ダーティパイプなどの脆弱性は、アップデートによって対処されます。コンテナからの脱出を許さないためには、これらのアップデートを比較的迅速に適用する必要があります。
もう一つ非常に効果的な対策は、openSUSE MicroOSやFlatcar Linuxのような、変更不可能なコンテナ指向のディストリビューションを使用することです。これらのディストリビューションは、読み取り専用のルート権限とアトミックなアップデートシステムを備えているため、攻撃対象領域を大幅に縮小し、パッチ適用後に問題が発生した場合でもロールバックを容易に行うことができます。
設定に関して：極めて厳密に管理された場合を除き、本番環境では特権コンテナを使用しないでください。コンテナ内でアプリケーションをroot権限で実行しないでください。可能な限り読み取り専用ファイルシステムを使用し、機能を必要最低限に制限してください。アプリケーションの実際の呼び出しに合わせて調整されたSELinux/AppArmorおよびseccompプロファイルは、事実上必須です。
最後に、ランタイム監視の側面も忘れてはなりません。Falco、Sysdig Secure、Aquaなどのツールは、異常、エスケープ試行（/procや/sysへの異常なアクセスなど）、非定型的なネットワークトラフィック、疑わしいコマンドなどを検出するのに役立ち、攻撃が本格化する前に対応するための時間を与えてくれます。
従来の仮想化とKVM、Podmanで管理されるコンテナ（ルートレスモードが望ましい）、適切にセグメント化されたネットワーク、そして適切なセキュリティ強化策を組み合わせることで、柔軟性が高く、極めて安全な仮想化プラットフォームを構築できます。共有カーネルが最も重要なポイントであることを理解し、リスクや規制コンプライアンスの要件に応じてVMまたはマイクロVMを活用し、イメージのサプライチェーンを慎重に管理することで、ラボ環境と本番環境対応のインフラストラクチャの違いが生まれます。
