「Podman」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
28行目: 28行目:
 
{{Warning|ルートレス Podman は非特権ユーザーの名前空間の使用 ({{ic|CONFIG_USER_NS_UNPRIVILEGED}}) に依存しています。これはいくつかの重大なセキュリティ上の影響があります。詳細は [[セキュリティ#アプリケーションのサンドボックス化]] を参照してください。}}
 
{{Warning|ルートレス Podman は非特権ユーザーの名前空間の使用 ({{ic|CONFIG_USER_NS_UNPRIVILEGED}}) に依存しています。これはいくつかの重大なセキュリティ上の影響があります。詳細は [[セキュリティ#アプリケーションのサンドボックス化]] を参照してください。}}
   
デフォルトではコンテナ (カーネルの文脈で言うところの名前空間) を実行できるのは {{ic|root}} だけです。
+
デフォルトではコンテナ (カーネルの文脈で言うところの名前空間) を実行できるのは {{ic|root}} だけです。ルートレスで Podman を実行すると、攻撃者がシステムに対するルート権限を持たないため、セキュリティが向上します。また、複数の非特権ユーザーが同じマシン上でコンテナを実行できるようになります。{{man|1|podman|Rootless mode}} も参照してください
   
  +
==== 追加の依存関係 ====
ルートレスで Podman を実行すると、攻撃者がシステムに対するルート権限を持たないため、セキュリティが向上します。また、複数の非特権ユーザーが同じマシン上でコンテナを実行できるようになります。 {{man|1|podman|Rootless mode}} も参照してください。
 
  +
  +
Podman を[https://github.com/containers/podman/blob/main/docs/tutorials/rootless_tutorial.md ルートレス環境]で動作させるために {{Pkg|fuse-overlayfs}} パッケージが必要です。
   
 
==== kernel.unprivileged_userns_clone を有効にする ====
 
==== kernel.unprivileged_userns_clone を有効にする ====
   
まず、次のコマンドを実行して {{ic|kernel.unprivileged_userns_clone}} の値を確認します
+
まず、次のコマンドを実行して {{ic|kernel.unprivileged_userns_clone}} の値を確認します:
   
 
$ sysctl kernel.unprivileged_userns_clone
 
$ sysctl kernel.unprivileged_userns_clone
   
現在、{{ic|0}} に設定されている場合は、[[sysctl]] または [[カーネルパラメータ]] で {{ic|1}} を設定して有効にします。
+
現在、{{ic|0}} に設定されている場合は、[[sysctl]] または[[カーネルパラメータ]]で {{ic|1}} を設定して有効にします。
   
 
{{Note|{{pkg|linux-hardened}} では {{ic|kernel.unprivileged_userns_clone}} がデフォルトで {{ic|0}} に設定されています。}}
 
{{Note|{{pkg|linux-hardened}} では {{ic|kernel.unprivileged_userns_clone}} がデフォルトで {{ic|0}} に設定されています。}}
44行目: 46行目:
 
==== subuid と subgid を設定する ====
 
==== subuid と subgid を設定する ====
   
ルートレスでPodmanを動かすには、使いたいユーザーごとに {{man|5|subuid}} と {{man|5|subgid}} 設定する必要りまこれらの情報は最終的に {{ic|/etc/subuid}} と {{ic|/etc/subgid}} にそのユーザ名前空間 UID リスアップされてい保されなければなりせん
+
ルートレスで Podman を動かすには、Podman を使用するユーザーに {{man|5|subuid}} と {{man|5|subgid}} 設定エントリ存在していなければなりません。{{man|8|useradd}} を使って作成された新しい[[ユーザー]]には、これらエントリデフォル在し
   
  +
{{Note|
{{ic|/etc/subuid}} と {{ic|/etc/subgid}} はデフォルトでは存在しません。もし、あなたのシステムにそれらがまだ存在しない場合は、次のコマンドを実行して作成します。
 
  +
{{pkg|shadow}} {{ic|4.11.1-3}} より前の時点で作成されたユーザーは、{{ic|/etc/subuid}} と {{ic|/etc/subgid}} 内にエントリがデフォルトで存在しません。{{man|8|usermod}} コマンドを使うか、これらのファイルを手動で変更することで、エントリを作成することができます。
   
  +
以下のコマンドは、{{ic|''username''}} というユーザとグループが Podman コンテナ (あるいは他の種のコンテナ) を実行できるようにします。このコマンドは、指定された範囲の UID と GID を、指定されたユーザとグループに割り当てます。
# touch /etc/subuid /etc/subgid
 
 
{{Note|以下で使用される ''usermod'' はこれらを作成しないため、上記のコマンドは必須です。}}
 
 
以下のコマンドは、{{ic|''username''}} ユーザーとグループが Podman コンテナ(またはその他の種類のコンテナ)を実行できるようにするものです。これは与えられた UID と GID の範囲を与えられたユーザーとグループに割り当てています。
 
   
 
# usermod --add-subuids 100000-165535 --add-subgids 100000-165535 ''username''
 
# usermod --add-subuids 100000-165535 --add-subgids 100000-165535 ''username''
   
  +
注意点として、{{ic|''username''}} に対する上記の範囲は、システム上の最初のユーザに対して定義されるため、他のユーザによってすでに取られているかもしれません。わからない場合は、まず {{ic|/etc/subuid}} と {{ic|/etc/subgid}} を調べて、すでに予約されている範囲を見つけてください。
{{Tip|''usermod'' コマンドを使う代わりに、{{ic|/etc/subuid}} と {{ic|/etc/subgid}} を直接編集してこれを実現することもできます。}}
 
 
これで、次のコンテンツが作成されます({{ic|''username''}} が指定したユーザー名に置き換えられます)。
 
 
{{hc|/etc/subuid|
 
''username'':100000:65536
 
 
}}
 
}}
   
  +
{{Note|
{{hc|/etc/subgid|
 
  +
* 多くのイメージはマッピングのために65536個の UID と GID を必要とします (特に busybox や alpine のベースイメージ)。docker との互換性を最大にするため、各ユーザに最低でもその数の UID と GID を割り当てることをお勧めします。
''username'':100000:65536
 
  +
* [[systemd-homed]] を使用している場合、コンテナ用の UID と GID の最小値は 524288 以上でなければなりません ({{ic|userdbctl}} の出力で "begin container users" を確認してください)。[https://www.reddit.com/r/podman/comments/uwgkb1/tip_systemdhomed_with_rootless_subuidsubgid/]
 
}}
 
}}
 
{{Note|多くのイメージはマッピングのために65536個の uids / gids を必要とします(特に busybox や alpine のベースイメージ)。docker との互換性を最大にするため、各ユーザに最低でもその数の uids / gids を割り当てることをお勧めします。}}
 
   
 
==== subuid と subgid の変更を伝播する ====
 
==== subuid と subgid の変更を伝播する ====
   
ルートレス Podman は非特権ネームスペースを存続させるために pause プロセスを使用します。これにより、{{ic|/etc/subuid}} および {{ic|/etc/subgid}} ファイルへの変更は、pause プロセスの実行中にルートレスコンテナに伝播されるのを防ぎます。これらの変更を伝播するには、以下のコマンドを実行します。
+
ルートレス Podman は非特権名前空間を存続させるために pause プロセスを使用します。これにより、{{ic|/etc/subuid}} および {{ic|/etc/subgid}} ファイルへの変更は、pause プロセスの実行中にルートレスコンテナに伝播されるのを防ぎます。これらの変更を伝播するには、以下のコマンドを実行します。
   
 
$ podman system migrate
 
$ podman system migrate
   
この後、上記のファイルで指定された user/group は、Podman コンテナを起動して実行できるようになります。
+
この後、上記のファイルで指定されたユーザ/グループは、Podman コンテナを起動して実行できるようになります。
   
 
=== ストレージ ===
 
=== ストレージ ===

2023年3月15日 (水) 00:03時点における版

関連記事

Podman は Docker の代わりになるプログラムで、同じようなインターフェイスを提供します。ルートレスコンテナとdocker-compose の shim サービスをサポートします。

インストール

podman パッケージをインストールしてください。コンテナイメージを作成したい場合は Buildah も見てください。

Docker と異なり、Podman はデーモンを必要としませんが、cockpit-podman など cockpit のようなサービスのための API は提供しています。

デフォルトでは Podman を実行できるのは root だけです。root 以外のユーザーでコンテナを実行したい場合はルートレス Podman を参照してください。

設定

コンテナの挙動を設定する設定ファイルは /usr/share/containers/ にあります。編集する前に /etc/containers にコピーする必要があります。Podman によって使われるネットワークブリッジインターフェイスを設定したいときは /etc/cni/net.d/87-podman-bridge.conflist を見てください。

ルートレス Podman

警告: ルートレス Podman は非特権ユーザーの名前空間の使用 (CONFIG_USER_NS_UNPRIVILEGED) に依存しています。これはいくつかの重大なセキュリティ上の影響があります。詳細は セキュリティ#アプリケーションのサンドボックス化 を参照してください。

デフォルトではコンテナ (カーネルの文脈で言うところの名前空間) を実行できるのは root だけです。ルートレスで Podman を実行すると、攻撃者がシステムに対するルート権限を持たないため、セキュリティが向上します。また、複数の非特権ユーザーが同じマシン上でコンテナを実行できるようになります。podman(1) § Rootless mode も参照してください。

追加の依存関係

Podman をルートレス環境で動作させるために fuse-overlayfs パッケージが必要です。

kernel.unprivileged_userns_clone を有効にする

まず、次のコマンドを実行して kernel.unprivileged_userns_clone の値を確認します:

$ sysctl kernel.unprivileged_userns_clone

現在、0 に設定されている場合は、sysctl またはカーネルパラメータ1 を設定して有効にします。

ノート: linux-hardened では kernel.unprivileged_userns_clone がデフォルトで 0 に設定されています。

subuid と subgid を設定する

ルートレスで Podman を動かすには、Podman を使用するユーザー毎に subuid(5)subgid(5) の設定エントリが存在していなければなりません。useradd(8) を使って作成された新しいユーザーには、これらのエントリがデフォルトで存在します。

ノート:

shadow 4.11.1-3 より前の時点で作成されたユーザーは、/etc/subuid/etc/subgid 内にエントリがデフォルトで存在しません。usermod(8) コマンドを使うか、これらのファイルを手動で変更することで、エントリを作成することができます。

以下のコマンドは、username というユーザとグループが Podman コンテナ (あるいは他の種のコンテナ) を実行できるようにします。このコマンドは、指定された範囲の UID と GID を、指定されたユーザとグループに割り当てます。

# usermod --add-subuids 100000-165535 --add-subgids 100000-165535 username

注意点として、username に対する上記の範囲は、システム上の最初のユーザに対して定義されるため、他のユーザによってすでに取られているかもしれません。わからない場合は、まず /etc/subuid/etc/subgid を調べて、すでに予約されている範囲を見つけてください。

ノート:
  • 多くのイメージはマッピングのために65536個の UID と GID を必要とします (特に busybox や alpine のベースイメージ)。docker との互換性を最大にするため、各ユーザに最低でもその数の UID と GID を割り当てることをお勧めします。
  • systemd-homed を使用している場合、コンテナ用の UID と GID の最小値は 524288 以上でなければなりません (userdbctl の出力で "begin container users" を確認してください)。[1]

subuid と subgid の変更を伝播する

ルートレス Podman は非特権名前空間を存続させるために pause プロセスを使用します。これにより、/etc/subuid および /etc/subgid ファイルへの変更は、pause プロセスの実行中にルートレスコンテナに伝播されるのを防ぎます。これらの変更を伝播するには、以下のコマンドを実行します。

$ podman system migrate

この後、上記のファイルで指定されたユーザ/グループは、Podman コンテナを起動して実行できるようになります。

ストレージ

コンテナイメージとインスタンスの保存方法と保存場所の設定は、/etc/containers/storage.conf にあります。

ノート: #ルートレス Podman を使用する場合、ストレージ設定のオーバーライドをユーザーごとに $XDG_CONFIG_HOME/containers/storage.conf に追加できます。

ストレージに使用しているファイルシステムに応じて driver を設定します (containers-storage.conf(5) § STORAGE_TABLE を参照)。

Foreign architectures

Podman is able to run images built for different CPU architecture than host using Wikipedia:binfmt_misc system.

To enable it install qemu-user-staticAUR and binfmt-qemu-staticAUR packages.

systemd comes with systemd-binfmt.service service which should enable new rules.

Verify that binfmt rules have been added:

ls /proc/sys/fs/binfmt_misc
DOSWin        qemu-cris        qemu-ppc      qemu-sh4eb        status
qemu-aarch64  qemu-m68k        qemu-ppc64    qemu-sparc        
qemu-alpha    qemu-microblaze  qemu-riscv64  qemu-sparc32plus  
qemu-arm      qemu-mips        qemu-s390x    qemu-sparc64      
qemu-armeb    qemu-mipsel      qemu-sh4      register

Podman should now be able to run foreign architecture images. Most commands use the foreign architecture when --arch option is passed.

Example:

podman run --arch arm64 'docker.io/alpine:latest' arch
aarch64

Docker Compose

Podman 3.0.0 introduces docker-compose support. This requires enabling a Podman socket which pretends to be docker; start the podman.service unit. For rootless containers, this requires you to start the podman.service user unit instead and set the DOCKER_HOST variable:

$ export DOCKER_HOST="unix://$XDG_RUNTIME_DIR/podman/podman.sock"

To get hostname resolution between containers running install podman-dnsname.

イメージ

ノート: イメージのレジストリプレフィックスは省略できます。Podman は /etc/containers/registries.confregistries.search に定義されている全てのレジストリからイメージを自動で (定義されている順番で) 検索します。以下に記述しているイメージは設定に docker.io がなくても使えるように全てプレフィックスを付けています。

Arch Linux

以下のコマンドで Arch Linux x86_64 イメージが Docker Hub から取得されます。ネットワークなどを除外した縮小版の Arch となっています。

# podman pull docker.io/archlinux

README.md も参照してください。

完全な Arch イメージを使いたい場合、リポジトリを複製して自分自身のイメージを作成してください。

$ git clone https://github.com/archlinux/archlinux-docker.git

devtools パッケージをインストールしてください。

packages ファイルを編集して 'base' とだけ記述し、以下のコマンドを実行:

# make rootfs
# podman build -t archlinux .

Alpine Linux

Alpine Linux はコンテナイメージとして容量が小さく、静的バイナリとしてコンパイルされたソフトウェアに適しています。以下のコマンドで最新の Alpine Linux イメージが Docker Hub から取得されます:

# podman pull docker.io/alpine

Alpine Linux はほとんどの Linux ディストリビューションで使われている glibc libc 実装の代わりに musl libc 実装を使っています。Arch Linux は glibc を使っているため、Arch Linux ホストと Alpine Linux コンテナにはパフォーマンスからソフトウェアの正確性まで様々な影響がある違いが存在します。C ライブラリの差異については こちら に記述されています。

Arch Linux (や glibc を使用する他の環境) で動的リンクでビルドしたソフトウェアは Alpine Linux (や他の libc を使用する環境) で実行したときにバグやパフォーマンスの問題が発生する可能性があります。例としては [2], [3], [4] を見てください。

CentOS

以下のコマンドによって最新の Centos イメージが Docker Hub から取得されます:

# podman pull docker.io/centos

CentOS のリリースを指定するタグについては Docker Hub のページを見てください。

Debian

以下のコマンドによって最新の Debian イメージが Docker Hub から取得されます:

# podman pull docker.io/debian

利用可能なタグについては Docker Hub のページを見てください。各 Debian リリース毎に standard と slim バージョンが存在します。

トラブルシューティング

イメージが見つからない

デフォルトでは、パッケージ内のファイルはアップストリームからのものであるため、レジストリリストは作成されません。つまり、デフォルトではレジストリを指定せずに任意のイメージを引っ張ってこようとすると、以下のようなエラーが発生します。

Error: short-name "archlinux" did not resolve to an alias and no unqualified-search registries are defined in "/etc/containers/registries.conf"

開始時の設定は次のようになります。

/etc/containers/registries.conf.d/00-unqualified-search-registries.conf
unqualified-search-registries = ["docker.io"]
/etc/containers/registries.conf.d/01-registries.conf
[[registry]]
location = "docker.io"

これはデフォルトの docker 設定と同等です。

コンテナがシェルログアウトで終了する

It may happen that after logging out from machine, Podman containers are stopped. To prevent that, user lingering should be enabled for user running containers:

$ loginctl enable-linger

You can also create user systemd unit as described: https://docs.podman.io/en/latest/markdown/podman-auto-update.1.html#examples

ルートレスモードでブリッジネットワークを使用してコンテナを作成する際にエラー

AppArmor を使用している場合、dnsname プラグインを有効にしてブリッジネットワークを使用してコンテナを作成すると、問題が発生する可能性があります:

$ podman network create foo
/home/user/.config/cni/net.d/foo.conflist
$ podman run --rm -it --network=foo docker.io/library/alpine:latest ip addr
Error: command rootless-cni-infra [alloc 89398a9315256cb1938075c377275d29c2b6ebdd75a96b5c26051a89541eb928 foo festive_hofstadter    ] in container 1f4344bbd1087c892a18bacc35f4fdafbb61106c146952426488bc940a751efe failed with status 1, stdout="", stderr="exit status 3\n"

これは、次の行を /etc/apparmor.d/local/usr.sbin.dnsmasq に追加することで解決できます:

owner /run/user/[0-9]*/containers/cni/dnsname/*/dnsmasq.conf r,
owner /run/user/[0-9]*/containers/cni/dnsname/*/addnhosts r,
owner /run/user/[0-9]*/containers/cni/dnsname/*/pidfile rw,

そして、AppArmor プロファイルをリロードします:

# apparmor_parser -R /etc/apparmor.d/usr.sbin.dnsmasq
# apparmor_parser /etc/apparmor.d/usr.sbin.dnsmasq

ルートレスモードでのコミット時にエラー

Error committing the finished image: error adding layer with blob "sha256:02823fca9b5444c196f1f406aa235213254af9909fca270f462e32793e2260d8": Error processing tar file(exit status 1) permitted operation

ストレージドライバが#ストレージ設定でオーバーレイされていることを確認します。

Error building pause image after Podman upgrade 3.x to 4.0

Error: building local pause image: finding pause binary: exec: "catatonit": executable file not found in $PATH

Install the catatonit package to fix the error.

For details on upgrading from 3.x to 4.0, see the official blog article

Container dns will not be enabled

WARN[0000]  binary not found, container dns will not be enabled

If you installed netavark as podman network backend you need to install aardvark-dns

failed to move rootless netns

docker-compose up
ERRO[0000] failed to move the rootless netns slirp4netns process to the systemd user.slice: Process org.freedesktop.systemd1 exited with status 1

podman.service起動/有効化することで解決します。

Permission denied: OCI permission denied

podman exec openvas_openvas_1 bash
Error: crun: writing file `/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/user.slice/libpod-b3e8048a9b91e43c214b4d850ac7132155a684d6502e12e22ceb6f73848d117a.scope/container/cgroup.procs`: Permission denied: OCI permission denied

Can be solved: https://bbs.archlinux.org/viewtopic.php?id=253966

env DBUS_SESSION_BUS_ADDRESS= podman ...
env DBUS_SESSION_BUS_ADDRESS= podman-compose ...

プロセスをポーズに追加

WARN[0000] Failed to add pause process to systemd sandbox cgroup: Process org.freedesktop.systemd1 exited with status 1 

https://github.com/containers/crun/issues/704 を使って解決できます。

# echo +cpu +cpuset +io +memory +pids > /sys/fs/cgroup/cgroup.subtree_control

参照