私はDockerコンテキストにあり、ユーザーの名前空間を使用してコンテナユーザーをホストユーザー(fooと仮定)にマップしています。 Portainerをコンテナとして使用するときは、Dockerソケットをバインドする必要があります。
$ll /var/run/docker.sock
srw-rw---- 1 root docker 0 nov. 14 11:47 /var/run/docker.sock
$sudo cat /etc/docker/daemon.json
{
"userns-remap": "foo"
}
$id
uid=1000(foo) gid=1000(foo) groupes=1000(foo),999(docker)
$getent group docker
docker:x:999:foo
私のfooユーザーがdockerグループのファイルにアクセスでき、Dockerが私のfooユーザーを使用してdockerプロセスを実行しても、私のportainerはソケットにアクセスできません。
この行を /etc/subgid に追加すると問題が解決します。
foo:999:1
この行の私の理解は次のとおりです。ユーザーfooは、999(999 + 0)から始まるgidを使用して最初のグループにアクセスできます。私のfooユーザーはdockerグループ999 gidにアクセスできます。
私が見ることができるように、次の違いがあります。
$getent group docker
docker:x:999:foo
そして
grep 999 /etc/subgid
foo:999:1
私の質問:これらの2つの設定の違いは何ですか?私のコンテナがDockerソケットにアクセスできるようにするためにsubgid設定が必要なのはなぜですか?
ありがとうございます!
答え1
ユーザーネームスペースマッピングあり
/etc/subuid for User IDs
/etc/subgid for Group IDs
コンテナコンテキストのユーザーIDが実際のホストIDにマップされる範囲を決定するために使用されます。
だから、
/etc/subuid > foo:100000:5000
例えば「0」に属するプロセス存在するコンテナは、実際には100000と5000の間のユーザーIDを持つホストのユーザーNSに属することができます。
一部のリソースがホストコンテキストから特定のユーザーIDに制限されている場合、コンテナのユーザーIDは実際のホストコンテキストでは問題ないように見えますが、IDはより高い範囲にあるため、リソースにアクセスできません。