저는 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
내 질문: 이 두 구성의 차이점은 무엇이며 내 컨테이너가 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는 더 높은 범위에 있으므로 리소스에 액세스할 수 없습니다.