Podman 6.0 — slirp4netns・CNI・cgroups v1削除、macOSのデフォルトプロバイダーはlibkrunに

はじめに — 27ヶ月ぶりのメジャー、そして静かに変わった所属
まず削除リストから — アップグレード前に自分の環境を確認
macOS — デフォルトプロバイダーがlibkrunに
pasta単独の時代 — そしてPestoという実験
Quadlet — .appファイルからサブディレクトリへ
Docker互換性の改善 = スクリプト動作の変化
CVE-2026-57231 — 5.8.3以下ならこれだけでもアップグレードする理由
では、いつアップグレードするか
おわりに
参考資料

はじめに — 27ヶ月ぶりのメジャー、そして静かに変わった所属

Podman 6.0.0が2026年6月24日にリリースされました。5.0.0は2024年3月19日だったので、27ヶ月ぶりのメジャーです。続いて7月8日に6.0.1と — 同じ日に — 5.8ブランチの5.8.5が一緒にリリースされました。旧世代ブランチがメジャーリリース直後にもパッチを受け取っているという事実自体が、本稿後半の「いつアップグレードするか」判断の重要な材料になります。

バージョン番号より先に目に付くのはリポジトリのアドレスです。リリースノートのイシューリンクはすべてgithub.com/podman-container-tools/podmanを指しています。PodmanはBuildah、Skopeoなどとともに「Podman Container Tools」という名前で2025年1月21日にCNCFサンドボックスに承認され(CNCFプロジェクトページ、Red Hatの発表)、6.0でGitHub組織の移動が実際に反映されました。Goインポートパスもgithub.com/containers/podman/v5からgo.podman.io/podman/v6に変わりました。ライブラリとしてPodmanをインポートするプロジェクトなら、これだけで移行作業です。

このブログではDockerからPodmanへの移行の話をすでに扱いました。その記事が「Podmanは5.x世代」と書いてから10日も経たないうちに6.0が出たわけで、本稿はその続編です — 6.0で何が削除され、デスクトップ(特にmacOS)で何が変わるのかを、リリースノート原文だけを基準に見ていきます。コンテナイメージのレイヤー周りの最新動向はcontainerdのEROFSネイティブレイヤーの記事で別途扱っており、本稿はランタイムとデスクトップのレイヤーに絞ります。

まず削除リストから — アップグレード前に自分の環境を確認

6.0は機能追加より削除が主役のリリースです。リリースノートのBreaking Changesをそのまま転記すると:

slirp4netns rootlessネットワークスタック削除 — pastaのみが残ります。専用オプションだった--network-cmd-pathも一緒に削除。
CNIネットワーキング削除 — Netavarkのみサポート。
iptablesサポート削除 — nftablesが必要。
cgroups v1システムサポート削除 — cgroups v2が必須。
BoltDBデータベースサポート削除 — 既存のBoltDBユーザーは6.0の初回起動時にSQLiteへの自動移行を試みます。
Intel Macサポート削除。
Windows 10サポート削除。

ここに付随スタックの要件が加わります。6.0.0はBuildah v1.44.0、Skopeo v1.23、Netavark・Aardvark v2.0.0と組み合わせて使う必要があり、設定ファイルのパースロジックが全面的に書き直され、別途設計文書が公開されました。ディストリビューションのパッケージを使う人はディストリ側がこの組み合わせを揃えてくれますが、自分でビルドしたり一部だけアップグレードしたりする人はバージョンの組み合わせを確認する必要があります。

自分の環境が削除対象に該当するかは、アップグレード前にこう確認できます。

# ネットワークバックエンドがcniなら6.0では動作しない(netavarkである必要がある)
podman info --format '{{.Host.NetworkBackend}}'

# rootlessネットワーキングがslirp4netnsに固定されていないか — containers.confを確認
grep -r "slirp4netns" ~/.config/containers/ /etc/containers/ 2>/dev/null

# DBバックエンド — boltdbなら6.0初回起動時にsqliteへの移行が走る
podman info --format '{{.Host.DatabaseBackend}}'

# cgroupsバージョン — v1ならまずホスト側を変える必要がある
podman info --format '{{.Host.CgroupsVersion}}'

BoltDB → SQLiteは自動移行があるとはいえ、「自動」という言葉を信じてバックアップなしにメジャーアップグレードするのはまた別の話です。コンテナを整理してからアップグレードするほうが安心です。

macOS — デフォルトプロバイダーがlibkrunに

macOSの話の背景を先に説明すると: 5.0(2024-03)でQEMUプロバイダーが削除され、Appleネイティブのハイパーバイザーベースのapplehv(内部的にはvfkit + Virtualization.framework)がデフォルトになり、5.2(2024-08)でlibkrunバックエンドが追加されました。当時のリリースノートが明示したlibkrunの利点は、GPUをVMにマウントして作業を高速化できることであり、デフォルトはapplehvのまま維持されました。

6.0がそのデフォルトを覆しました。リリースノート原文: "The default podman machine provider on Macs has been changed to libkrun." ローカルLLM推論のようにVM内でGPUを使いたい需要が大きくなっている状況と無関係ではなさそうな選択に見えます(推測ではなく、5.2のノートが明示したlibkrunの存在理由がGPUマウントです)。

実務上重要な点:

既存のVMはそのままです。変わるのは新規作成するVMのデフォルトプロバイダーです。6.0からはすべてのpodman machineコマンドが現在の設定にかかわらずすべてのプロバイダーのVMを扱えるようになり、applehv VMとlibkrun VMを混在させる運用がかえって扱いやすくなりました。
引き続きapplehvを使いたい場合はpodman machine init --provider applehvと明示すれば済みます。このオプション自体が6.0の新機能です。
Intel Macは6.0でサポートが削除されたため、この議論自体が該当しません — 5.8.xにとどまる必要があります。

そして正直に見るべき部分。libkrunがデフォルトになるほど成熟しているかについては、根拠が割れています。6.0.1と5.8.5が同じ日に修正したバグは「ホストのポートスキャンプロセスがlibkrun VMに意図せずシャットダウンコマンドを送り、VMが周期的に落ちる」問題でした — デフォルト昇格からわずか2週間で出た最初のパッチがこれだったということです。また、2025年12月のあるdiscussionでは、講義環境でlibkrunを使う際にバインドマウントの権限問題(報告者自身の集計では受講者の約4分の1がホストディレクトリの権限を777に緩める必要があった)が報告されており、applehvでは再現しなかったとのことです。個別ユーザーの報告なので一般化はできませんが、-vバインドマウント中心で作業する人であれば、デフォルトに従う前に自分のワークフローで確認してみる理由にはなります。

Windows側についても触れておくと: Windows 10のサポートが削除された代わりに、hypervプロバイダーVMの起動・停止に管理者権限が不要になり(作成は依然として必要で、新規VMにのみ適用)、管理者がホストを事前に準備できるpodman system hyperv-prepコマンドが追加されました。

pasta単独の時代 — そしてPestoという実験

slirp4netnsの削除は突然ではありません。5.0ですでにrootlessのデフォルトネットワーキングがslirp4netnsからpastaに変わっており("for improved performance" — 5.0のリリースノート)、6.0は2年以上デフォルトでなかったコードを削除したにすぎません。それでもcontainers.confやスクリプトにslirp4netnsが埋め込まれた環境は残っているはずなので、上のgrep一行は実行してみる価値があります。

pasta単独時代に知っておくべき動作特性が一つ: Podmanネットワーキングチュートリアルが明示するように、pastaモードのコンテナはデフォルトで互いに隔離されています。ブリッジのような仮想ネットワークがあるわけではないので、コンテナ間の通信はホストのポートマッピングを経由するか、同じPodに入れてネットワークネームスペースを共有する必要があります。rootlessでコンテナ同士が直接通信する必要がある場合は、rootless netavarkブリッジネットワークを作るのが定石です。

ただ、rootlessブリッジには古くからの痛みがあります — ポートフォワーディングを担うrootlessportがプロキシとして挟まることで、コンテナから見えるクライアントのソースIPが実際のアドレスではなくなる問題です。接続ログが全部ゲートウェイのアドレスになっているのを見た経験がある人ならわかるはずです。6.0はここに実験的な代替案を入れました: containers.confで次のように設定すると、

[network]
rootless_port_forwarder = "pasta"

rootlessブリッジネットワークのポートフォワーディングがrootlessportではなくPestoというツールによって、pastaのカーネルレベルフォワーディングで処理されるようになります。ソースコードの説明によれば、rootlessネームスペース内の共有pastaインスタンスがホスト側のフォワーディングを担い、localhostトラフィックはカーネルsplice、外部トラフィックはTAPで転送しつつソースIPを保持します — コンテナがプロキシやゲートウェイのアドレスではなく実際のクライアントアドレスを見られるようになります。

期待できる機能ですが、期待値は下げておくべきです。デフォルトは依然としてrootlessportであり、リリースノート自身が「安定性がより確実になれば切り替えを検討する」と書いており、pestoバイナリを含むpasstバージョン(passt-0^20260507.g1afd4ed以上)が必要です。そして6.0.1はすでにPestoのルールクリーンアップのバグ(コンテナ再起動やネットワークリロード時にルールがクリーンアップされずフォワーディングが失敗する)を修正しています。「実験的」というラベルは飾りではないということです。ソースIPが切実に必要な環境(fail2ban系、アクセス制御、監査ログ)でオプトインとして検証する段階であり、本番のデフォルトとして使う段階ではありません。

付録的な実験をもう一つ: カーネル6.18以降では、rootlessユーザーネームスペースを保持するためのpauseプロセスをnsfsファイルハンドルに置き換える機能が入りました。drop-pause-process環境変数の裏に隠れた実験機能ですが、rootless Podmanの長年の構造物の一つが消える可能性があるという兆候です。

Quadlet — .appファイルからサブディレクトリへ

systemdユニットでコンテナを管理するQuadlet側にも構造変化があります。従来はpodman quadlet installでインストールしたQuadletと付随ファイルを.appファイルとして追跡していましたが、6.0からはサブディレクトリに配置する方式に変わりました。リリースノートはバグが減り手動管理が楽になると説明しています — 逆に言えば、.app方式に依存していたスクリプトやドキュメントは修正対象です。

その他のQuadlet変更点:

.volumeユニットにUID・GID・Optionsキーを追加(作成時に所有者と一般的なボリュームオプションを指定可能)。
.containerユニットでソースなしのMountキーによる匿名ボリュームマウントが可能に。
ディストリビューションがQuadletをパッケージングして配布できるよう/usr/share/containers/systemd/users系の検索パスを追加(ユーザーUID別のサブパスを含む)。
podman quadlet listにstatusフィルタ、Pod列、lsエイリアス、--noheadingを追加。
Quadletのmanページがファイルタイプ別に分割。

podman generate systemdが旧式になりQuadletが正解になる流れは移行ガイドで扱った通りですが、6.0はそのQuadletを「ディストリビューションがパッケージとして配布できるもの」にする方向です。コンテナをsystemdサービスとしてデプロイするパターンが一級市民になりつつある兆候として読めます。

Docker互換性の改善 = スクリプト動作の変化

6.0のBreaking Changesの多くは「Dockerと同じにする」ものです。互換性の改善は歓迎すべきことですが、裏を返せば、既存のPodmanの動作に合わせて書かれたスクリプトが静かに違う動作をするということです。引っかかりやすいもの:

podman volume pruneが今後Dockerと同様、匿名ボリュームのみを削除します。以前のようにすべての未使用ボリュームを削除するには新しい--allオプションが必要です。削除対象を事前に確認できる--dry-runも一緒に追加されました。
podman volume listの複数フィルタがORからANDに変わり、複数のコマンドのlabel!=フィルタも同様にAND結合になりました。フィルタを複数かけていたクリーンアップスクリプトは結果セットが変わります。
ps・pod ps・volume lsでLabelsフィールドをJSON形式で取得すると、JSONマップではなくカンマ区切りのkey=value文字列が返るようになりました(Docker互換)。この出力をjqでパースしていたパイプラインは壊れます。
podman commitがデフォルトでコンテナを一時停止してからコミットするようになりました(同時変更防止)。以前の動作は--pause=false。
ネットワーク分離がデフォルトで有効になり、Docker互換APIバージョンがv1.44に上がりました。
--gpusオプションがAMD GPUに対応しました(従来NVIDIA専用だったものの拡張)。

「Docker互換が良くなった」という文を読んで流すのは簡単ですが、CIやクリーンアップのcronジョブでvolume pruneやフィルタの意味が変わったのは、実際にデータが削除される仕組みが変わったということです。アップグレード後の最初の実行は注視することを勧めます。

CVE-2026-57231 — 5.8.3以下ならこれだけでもアップグレードする理由

6.0.0と同時に公開されたセキュリティ修正が一つあります。GHSA-4hq8-gpf5-8p68(CVE-2026-57231、GitHub深刻度high): 悪意あるイメージが細工したEnv項目でホストの環境変数をコンテナ内に漏洩させることができ、ワイルドカードのglobを使えば変数名を知らないまま大量に漏洩させることが可能でした。影響範囲はv1.8.1以上v5.8.3以下 — 事実上ここ数年のほぼすべてのバージョンです。修正はv5.8.4(2026-06-26)とv6.0.0に入りました。

「イメージをpullしてrunするだけでホストの環境変数が漏れる」類の脆弱性は、デスクトップユーザーに特に痛いものです。開発マシンとはシェル環境にAPIキーやトークンをexportして暮らしている環境だからです。6.0へ移行する予定がなくても、5.8.3以下なら5.8.4以上へは上げる必要があります。

では、いつアップグレードするか

今アップグレードして良い場合:

Apple Silicon Macで新規に始める場合。Homebrewは本稿執筆時点(2026-07-17)ですでに6.0.1をstableとして配布しており、brewユーザーは事実上すでに6.0トラックにいます。既存のapplehv VMを維持するか、libkrunで新規に作るかを決めるだけです。
ネットワークバックエンドがすでにnetavark + pastaで(5.xのデフォルトをそのまま使ってきた場合はほぼ該当)、BoltDBではなくSQLite DBを使っている場合 — 上の確認コマンドで数秒で判別できます。
Docker互換APIを消費するツール(composeなど)を使っている場合 — API v1.44と互換性修正の恩恵を受けます。

待つか5.8.xにとどまるべき場合:

Intel Mac、Windows 10 — 選択肢がありません。5.8.xが唯一のトラックであり、5.8.5が6.0.1と同じ日に出たことを見ると、当面パッチは続きそうです(ただし公式のサポート期間が明示されているわけではありません)。
cgroups v1ホスト、CNIネットワーク構成が残っているサーバー — ホスト・ネットワークの移行が先です。
バインドマウント中心のmacOSワークフロー — libkrunのデフォルトをそのまま追う前に自分のワークロードで権限の動作を確認するか、当面--provider applehvを明示するのが保守的です。
ps・volumeの出力やpruneの動作をパース・依存する自動化が多い環境 — 上の互換性変化リストを先に監査してからアップグレードするほうが安全です。

一つ付け加えると、podman machine os applyがbootc switchベースに書き直されたのも6.0の静かな変化です。machine VMのOSアップデートがブート可能なコンテナイメージへの切り替えとして処理されるということで、不変OSの流れがデスクトップVMにまで降りてきたことになります(サーバー側の不変OSの話はTalos 1.13の記事を参照)。

おわりに

Podman 6.0は新機能で誘うリリースではなく、負債を清算するリリースです。slirp4netns・CNI・iptables・cgroups v1・BoltDB — いずれも数年前から後継が決まっていたものであり、6.0はその猶予期間の終了宣言です。その上に、CNCF移管というガバナンスの変化、macOSのlibkrun移行というデスクトップの変化、そしてPestoというrootlessネットワーキングの次の実験が重なっています。

アップグレードの判断はシンプルです。上のpodman info 3行で削除リストに該当するか確認し、該当するならまずそれを解消し、macOSならプロバイダーを意識的に選び、自動化が多いならDocker互換性変化のリストを監査してからアップグレードすればよいのです。そしてどちらにせよ、5.8.3以下にはとどまらないでください — CVE-2026-57231一つだけでも理由は十分です。