「Podman 6.0」登場、5つのレガシー技術を完全廃止　移行前の監査が必須に

2026年6月24日にリリースされた「Podman 6.0.0」では、約10年にわたりLinuxコンテナ環境を支えてきた5つの基盤コンポーネント（cgroups v1、iptables、CNI、slirp4netns、BoltDB）が完全に削除された。これにより、モダン化を進めてこなかった開発チームには移行の猶予が残されていない。本稿では、DevOpsエンジニアやプラットフォーム運用者がアップグレード前に確認すべき重大な変更点と、同時に修正された脆弱性について解説する。

■5つの非互換変更と移行の猶予期間

Podman 6.0における5つのコンポーネント削除は、2022年のPodman 4.0から始まった非推奨サイクルの最終段階である。1年以上前から警告されていた変更が、今回のマイルストーンで恒久的なものとなった。

1つ目は「cgroups v1」の廃止だ。Linuxカーネルの初代リソース制御メカニズムに代わり、2016年のLinux 4.5で導入された統合階層構造「cgroups v2」への移行が必須となる。cgroups v2が有効になっていないシステムでは、Podman 6.0は起動しない。特に、Red Hat Enterprise Linux（RHEL）8はデフォルトでcgroups v1を使用しているため、アップグレード前にカーネル起動パラメータに「systemd.unified_cgroup_hierarchy=1」を追加して再起動する必要がある。なお、RHEL 9以降やUbuntu 21.10以降などはデフォルトでcgroups v2が有効になっている。

2つ目は「iptables」から「nftables」への完全移行だ。Podmanは今後、コンテナのネットワークルールをnftablesのみで記述する。同じホスト上でDocker（iptablesに依存）とPodman 6.0を共存させる場合、両方のフレームワークが混在することになるため、アップグレード前にファイアウォール管理ツールの互換性を監査する必要がある。

3つ目は「CNI（Container Network Interface）」のサポート終了と、Rust製の「Netavark」への移行だ。NetavarkはPodman専用に開発されたネットワークスタックであり、単一ノードでのコンテナ管理やDNS解決を高速に行う。独自のCNIプラグインを使用している組織は、そのロジックをNetavarkに移植するか、代替手段を見つけない限りPodman 6.0へ移行できない。

4つ目は、ルートレスコンテナ用のTCP/IPスタック「slirp4netns」から「Pasta」への移行だ。Pastaはカーネルのネットワーク名前空間とホスト側のフォワーディングを利用し、ネイティブに近いネットワーク速度を実現する。利用にはLinux 5.x以降のカーネルが必要となる。

5つ目は、メタデータ保存先としての「BoltDB」から「SQLite」への移行だ。Podman 6.0を起動すると、自動的にSQLiteへの一方向の移行が実行される。本番環境に適用する前に、ステージング環境で移行挙動を検証することが推奨される。

■外部イメージ取得時に影響する脆弱性（CVE-2026-57231）

Podman 6.0.0では、サプライチェーンの脆弱性「CVE-2026-57231」が修正された。この脆弱性は、悪意のあるコンテナイメージがマニフェスト内の不正な環境変数（Env）エントリを利用して、ホスト環境の環境変数（シークレットや資格情報を含む）を窃取できてしまうというものだ。影響を受けるバージョンは1.8.1から5.8.3までである。

この修正は、2026年6月26日にリリースされた「Podman 5.8.4」にもバックポートされている。そのため、6.0の非互換変更にすぐに対応できないチームであっても、5.8.4にアップグレードすることでセキュリティパッチのみを即座に適用可能だ。パブリックレジストリからイメージを取得して実行する環境では、最優先で適用が推奨される。

■AMD製GPUのサポートとその他の新機能

AIの推論や学習ワークロードをコンテナで実行するチームにとって、Podman 6.0の目玉となる追加機能は「AMD製GPU」のネイティブサポートだ。「podman create」および「podman run」の「--gpus」フラグがAMD製GPUデバイスを認識するようになり、AMD Radeon InstinctやRadeon PROなどのインフラを利用している組織の利便性が向上した。

また、コンテナネットワークにおいて「--net」の「ip=」オプションを複数回指定できるようになり、単一コンテナに複数の静的IPアドレスを割り当てることが可能になった。さらに「podman network create」コマンドにblackholeなどのルートを作成する機能が追加され、コンテナがアクセスできる外部ネットワークを細かく制御できるようになった。

■Quadletの新しいディレクトリ構造

コンテナをsystemdサービスとして実行するための仕組み「Quadlet」の構造が再編成された。従来の「.app」ファイルによる管理から、Quadletと関連ファイルを専用のサブディレクトリにまとめて配置するレイアウトに変更された。これによりバグが削減され、手動管理が容易になるという。また、「.volume」ユニットに「UID=」「GID=」「Options=」の3つの新しいキーが追加された。

■Podman Machineとボリュームの変更点

Podman Machine VM内のOSを更新する「podman machine os update」コマンドが新しく追加された。また、起動時にホストシステムの信頼されたCA証明書ストアをインポートする「--import-native-ca」フラグも追加されている。

注意が必要な点として、Linux上のPodman Machine VMは、ホストボリュームのマウントに従来の仕組みではなくsystemdを使用するようになった。6.0へのアップグレード前に作成された既存のLinux VMはこの新しいマウントパスを使用できないため、アップグレード後にVMを再作成する必要がある。

さらに、ボリュームのクリーンアップ動作がDocker仕様に合わせて変更された。「podman volume prune」を実行した際、デフォルトでは未使用の「匿名ボリューム」のみが削除され、名前付きボリュームは維持される。従来の挙動（名前付きも含めてすべて削除）を維持したい場合は、新設された「--all」フラグを使用する。また、削除対象を事前に確認できる「--dry-run」オプションも追加された。

■互換性マトリクス：5つの依存関係を同時に更新

Podman 6.0は、設定ファイルのパースやネットワークスタックの挙動に影響する構造変更が行われているため、単体でのアップグレードは推奨されない。以下のコンポーネントを同一のメンテナンスウィンドウで同時に更新する必要がある。

・Buildah 1.44
・Skopeo 1.23
・NetavarkおよびAardvark 2.0
・container-libs common/v0.68

なお、プロジェクトのGoモジュールインポートパスは、CNCF傘下のGitHub組織への移行に伴い「github.com/containers/podman/v5」から「go.podman.io/podman/v6」に変更された。Podmanのライブラリを直接インポートしているGoプロジェクトは、インポート文の更新が必要となる。

■注目ポイントQ&A

●Podman 5.xのまま、脆弱性（CVE-2026-57231）の修正パッチだけを適用することはできますか？

はい、可能です。この環境変数漏洩の脆弱性に対する修正は、2026年6月26日にリリースされた「Podman 5.8.4」にバックポートされています。Podman 6.0の非互換変更に対応する準備が整っていない場合は、5.8.4にアップグレードすることで、新スタックへの移行を避けつつ脆弱性に対処できます。

●同じLinuxホスト上でDockerとPodmanを併用している場合、どのような影響がありますか？

Podman 6.0はコンテナネットワークルールにnftablesを要求しますが、Dockerは引き続きiptablesを使用します。同一ホスト上で両者が共存することは技術的に可能ですが、バックエンドの断片化が発生します。混在環境で運用している場合は、アップグレード前にファイアウォール自動化ツールの互換性を確認してください。

●Podman 6.0はRed Hat Enterprise Linux 8（RHEL 8）で動作しますか？

そのままでは動作しません。RHEL 8はデフォルトでcgroups v1を使用していますが、Podman 6.0はこれをサポートしていません。動作させるには、カーネル起動パラメータに「systemd.unified_cgroup_hierarchy=1」を追加してcgroups v2を有効にし、システムを再起動する必要があります。この変更がホスト上の他のソフトウェアに影響を与えないか、事前に検証してください。

●Podman 6.0のAMD製GPUサポートはどのように機能しますか？

「podman create」および「podman run」コマンドの「--gpus」フラグで、NVIDIAに加えてAMD製GPUデバイスを指定できるようになりました。これはContainer Device Interface（CDI）仕様を利用しており、AMD Radeon InstinctやRadeon PROなどのインフラを使用している環境で、ルート権限不要のPodmanコンテナからGPUアクセラレーションを利用したAI推論や学習ワークロードを実行可能にします。

元記事: Podman 6.0 Cuts Five Legacy Layers: What Container Teams Must Audit Before Upgrading