Docker 컨테이너 root 권한이 걱정될 때 userns-remap 설정 방법

컨테이너 안에서 root로 실행되는 프로세스가 곧바로 호스트 root가 되는 구조가 걱정된다면 Docker의 userns-remap을 검토할 수 있습니다. 이 기능은 컨테이너의 UID 0을 호스트의 높은 비특권 UID 범위로 매핑합니다. 다만 Docker 데몬 자체는 root로 계속 실행되고, 기존 이미지·컨테이너가 바로 보이지 않으며, bind mount 권한도 달라집니다. 운영 서버에서는 설정 한 줄을 추가하기 전에 저장소와 마운트 의존성을 먼저 점검해야 합니다. 소프트모아의 서비스와 포트폴리오는 softmoa.com에서 확인할 수 있습니다.

userns-remap이 바꾸는 UID

기본 Docker에서는 컨테이너의 UID 0이 호스트 UID 0과 같은 번호로 보일 수 있습니다. userns-remap을 켜면 컨테이너 안에서는 여전히 root로 보이지만, 호스트에서는 별도 범위의 UID로 실행됩니다. 예를 들어 dockremap:231072:65536이 /etc/subuid와 /etc/subgid에 있으면 컨테이너 UID 0은 호스트 UID 231072에 대응하고, 컨테이너 UID 1은 231073에 대응합니다. 이 매핑이 컨테이너 탈출 취약점의 피해 범위를 줄일 수는 있어도, 마운트한 비밀 파일을 읽게 한 문제나 애플리케이션 내부 권한 문제까지 해결하지는 않습니다.

또한 애플리케이션을 컨테이너 내부에서 불필요하게 root로 실행하지 않는 원칙은 그대로 필요합니다. userns-remap은 root 실행을 허용하는 이유가 아니라, 기존 이미지가 root를 요구하는 경우에 호스트 권한을 분리하는 보완 장치로 보는 편이 맞습니다.

전환 전에 확인할 대상

• 기존 Docker 저장소: 기능을 켜면 Docker는 UID·GID가 붙은 별도 경로에 데이터를 두므로, 기존 이미지·컨테이너·볼륨이 새 설정에서 즉시 보이지 않습니다. 재배포 순서와 백업 복구 절차를 정한 뒤 전환합니다.
• bind mount: 호스트의 /srv/app-data를 컨테이너에 쓰기 가능하게 연결했다면, 기존 소유자가 아니라 매핑된 UID 범위가 쓸 수 있는지 확인해야 합니다. 임의로 전체 권한을 열기보다 전용 경로와 필요한 소유권만 준비하는 편이 안전합니다.
• 호스트 공유 옵션: --pid=host, --network=host, 일부 외부 볼륨 드라이버와의 조합에는 제약이 있습니다. --privileged가 필요한 컨테이너도 별도 검토가 필요합니다.
• 예외 컨테이너: --userns=host는 특정 컨테이너의 매핑을 끕니다. 단순한 권한 오류를 피하려고 이 옵션을 넓게 적용하면 전환 목적이 약해집니다.

daemon.json에 적용하는 기본 설정

새 설치이거나 전환 계획을 검토한 환경에서는 기존 /etc/docker/daemon.json의 JSON 속성을 보존한 채 userns-remap을 추가합니다. 파일이 비어 있는 경우의 최소 예시는 다음과 같습니다. default를 사용하면 Docker가 dockremap 사용자와 매핑을 준비합니다. 배포판에 따라 subordinate UID·GID 항목이 자동 생성되지 않을 수 있으므로 재시작 후 반드시 확인합니다.

{
  "userns-remap": "default"
}

운영 중인 Docker 호스트에서는 이 파일을 덮어쓰면 기존 로그 설정, 레지스트리 미러, 데이터 루트 같은 항목을 잃을 수 있습니다. 현재 JSON에 쉼표와 속성 위치를 맞춰 병합하고, 별도 유지보수 시간에 Docker를 재시작합니다. 이 변경은 실행 중 컨테이너에 즉시 적용되는 옵션이 아닙니다.

재시작 후 읽기 전용으로 확인하는 방법

아래 명령은 설정 여부와 매핑 계정의 범위를 읽습니다. 첫 두 명령에서 계정 또는 범위가 보이지 않으면, 재시작만 성공한 것으로 판단하지 말고 /etc/subuid와 /etc/subgid 구성을 확인해야 합니다.

sudo id dockremap
sudo grep '^dockremap:' /etc/subuid /etc/subgid
docker info --format '{{json .SecurityOptions}}'
sudo ls -ld /var/lib/docker/*.*

마지막 경로의 숫자는 환경마다 다릅니다. 중요한 것은 컨테이너 root가 호스트의 0이 아닌 매핑 범위로 보이는지입니다. 테스트 컨테이너를 별도 점검 창에서 실행한다면, 호스트의 프로세스 UID와 매핑 범위를 비교한 뒤 바로 제거합니다. 이미지 목록이 비어 보이는 현상은 설정 실패로 단정할 일이 아니라, remap 저장소로 전환되었을 때 나타날 수 있는 동작입니다.

권한 오류를 만났을 때의 판단 순서

전환 뒤 컨테이너가 파일을 쓰지 못하면 먼저 컨테이너 UID를 다시 host 모드로 돌리지 말고, 해당 경로가 bind mount인지와 필요한 읽기·쓰기 권한을 구분합니다. 데이터베이스처럼 컨테이너가 소유해야 하는 지속 데이터는 named volume이 관리하기 쉬울 수 있습니다. 꼭 호스트 경로를 연결해야 한다면 그 서비스만 쓰는 디렉터리를 만들고 매핑된 UID·GID에 필요한 최소 권한을 부여합니다. 구성 파일을 읽기 전용으로 연결하는 경우에도 파일 모드와 실제 프로세스 UID를 확인해야 합니다.

userns-remap과 rootless Docker는 같은 설정이 아닙니다. 전자는 root로 동작하는 Docker 데몬을 유지하면서 컨테이너 UID를 매핑합니다. rootless Docker는 데몬과 컨테이너를 일반 사용자 권한으로 실행합니다. 호스트 네트워크나 특권 모드 의존성이 많은 기존 환경이라면 기능 호환성부터 확인하고, 새로 만드는 단일 사용자 환경이라면 rootless 방식까지 함께 비교하는 것이 좋습니다.

공식 문서로 다시 확인할 항목

• Docker의 userns-remap 안내에서 subordinate UID·GID, 기존 저장소 전환, 호스트 네트워크와 privileged 제약을 확인합니다.
• UID/GID 매핑 문서에서 rootless Docker와의 매핑 차이를 확인합니다.

소프트모아는 해당 시스템을 구축합니다. 문의하기