Windows 권한 요구 사항 이해하기

이 페이지는 Windows에서 Docker Desktop을 실행하고 설치하기 위한 권한 요구 사항, privileged helper 프로세스 com.docker.service의 기능, 그리고 이 접근 방식의 이유에 대한 정보를 담고 있어요. 또한 컨테이너를 root로 실행하는 것과 호스트에서 Administrator 접근을 갖는 것의 차이, Docker Engine과 Windows 컨테이너의 권한도 명확히 설명해요. Windows의 Docker Desktop은 보안을 염두에 두고 설계됐으며, 관리자 권한은 정말 필요할 때만 요구돼요.

출처: Understand permission requirements for Windows

본문

권한 요구 사항

Docker Desktop을 설치하고 실행하는 데 필요한 권한은 설치 모드에 따라 달라져요.

Per-user 설치

per-user 모드에서 Docker Desktop은 %LOCALAPPDATA%\Programs\DockerDesktop에 설치되고 현재 사용자 레지스트리 키(HKCU)에만 써요. 즉:

Docker Desktop 설치/업데이트에 관리자 권한이 필요 없어요.
설치 후 관리자 권한 없이 실행할 수 있어요.
Settings에서 Requires password 로 표시된 일부 설정은 여전히 elevation을 요구해요. 이런 설정을 바꾸고 Apply 를 선택하면 Docker Desktop이 관리자 접근을 위한 UAC 프롬프트를 열어요.

per-user 설치는 privileged helper 서비스 com.docker.service를 자동으로 설치하지 않아요. 그래서 Hyper-V 백엔드와 Windows 컨테이너처럼 그것에 의존하는 기능은 사용할 수 없어요. Docker VMM(Beta)은 per-user 모드에서 사용 가능하고 privileged helper가 필요 없어요. 대부분의 사용자에게 WSL 2나 Docker VMM 백엔드가 대부분의 사용 사례를 충족해요.

All-users 설치

all-users 모드에서 Docker Desktop은 C:\Program Files\Docker\Docker에 설치되고 Local Machine 레지스트리 키(HKLM)에 써요. 두 위치 모두 수정에 관리자 권한이 필요하므로:

Docker Desktop 설치/업데이트에 관리자 권한이 필요해요.
설치 시 privileged helper 서비스 com.docker.service를 설치할 수 있게 하는 UAC 프롬프트를 받아요.
설치 후에는 관리자 권한 없이 실행할 수 있어요.

privileged helper 없이 Docker Desktop을 실행하는 데 docker-users 그룹 멤버십은 필요 없어요. 하지만 privileged 작업이 필요한 일부 기능은 이 요구 사항이 있어요. 설치를 한 사용자는 자동으로 docker-users 그룹에 추가되지만, 다른 사용자는 수동으로 추가해야 해요. 이를 통해 관리자는 Hyper-V VM 생성/관리, Windows 컨테이너 사용 같은 더 높은 권한이 필요한 기능에 접근할 사람을 제어할 수 있어요.

Docker Desktop이 시작되면 모든 비privileged named pipe가 생성되어 다음 사용자만 접근할 수 있어요.

Docker Desktop을 시작한 사용자.
로컬 Administrators 그룹 멤버.
LOCALSYSTEM 계정.

항상 elevation이 필요한 작업

설치 모드와 관계없이 다음은 관리자 권한이 필요해요.

첫 WSL 2 활성화: Docker Desktop이 실행되기 전에 머신에서 WSL 2를 활성화해야 해요. 머신당 한 번의 작업이고, 한 번 활성화하면 이후 Docker Desktop 설치/업데이트에 다시 필요하지 않아요.
Requires password로 표시된 설정: 일부 Docker Desktop 설정은 시스템 수준 구성을 변경해서 적용에 관리자 자격 증명이 필요해요. 이런 설정을 바꾸고 Apply 를 선택하면 관리자 자격 증명을 요구해요.

Privileged helper

Docker Desktop은 privileged helper 프로세스 com.docker.service가 수행하는 제한된 privileged 작업 집합을 수행해야 해요. 이 접근 방식은 최소 권한 원칙에 따라 Administrator 접근을 꼭 필요한 작업에만 사용하면서도 Docker Desktop을 unprivileged 사용자로 사용할 수 있게 해줘요.

참고: com.docker.service는 all-users 설치 모드에서만 설치돼요. per-user 설치는 WSL 2 또는 Docker VMM 백엔드에 의존하고 Hyper-V나 Windows 컨테이너를 지원하지 않으므로 사용되지 않아요.

privileged helper com.docker.service는 SYSTEM 권한으로 백그라운드에서 실행되는 Windows 서비스예요. named pipe //./pipe/dockerBackendV2에서 리슨해요. 개발자는 Docker Desktop 애플리케이션을 실행하고, 이 애플리케이션은 named pipe에 연결해 서비스에 명령을 보내요. 이 named pipe는 보호되며 docker-users 그룹의 사용자만 접근할 수 있어요.

서비스는 다음 기능을 수행해요.

kubernetes.docker.internal이 Win32 hosts 파일에 정의되도록 보장.
host.docker.internal과 gateway.docker.internal이 Win32 hosts 파일에 정의되도록 보장. 호스트 로컬 IP를 가리켜 애플리케이션(호스트 또는 컨테이너)이 같은 이름으로 호스트 IP를 해석하게 해줘요.
Hyper-V VM "DockerDesktopVM" 생성 및 수명주기 관리(시작/정지/파괴). VM 이름은 서비스 코드에 하드 코딩되어 있어서 다른 VM을 만들거나 조작하는 데 사용할 수 없어요.
VHDX 파일 또는 폴더 이동.
Windows Docker Engine 시작/정지 및 실행 여부 조회.
모든 Windows 컨테이너 데이터 파일 삭제.
Hyper-V 활성화 여부 확인.
부트로더가 Hyper-V를 활성화하는지 확인.
필요한 Windows 기능이 설치되고 활성화됐는지 확인.
자체 버전 조회와 healthcheck 수행.
개발자에게 읽기 전용인 Registry Access Management 정책의 안전한 캐싱. (4.88.0 및 이전 버전 적용)

서비스 시작 모드는 선택한 컨테이너 엔진에 따라, WSL의 경우 Win32 hosts 파일에서 host.docker.internal, gateway.docker.internal을 유지해야 하는지에 따라 달라져요. 이는 설정 페이지의 Use the WSL 2 based engine 아래 설정으로 제어돼요. 설정하면 WSL 엔진이 Hyper-V처럼 동작해요.

Windows 컨테이너나 Hyper-V Linux 컨테이너에서는 서비스가 시스템 부팅 시 시작되고, Docker Desktop이 실행 중이 아니어도 항상 실행돼요. 이는 관리자 권한 없이 Docker Desktop을 실행할 수 있게 하기 위해 필요해요.
WSL2 Linux 컨테이너에서는 서비스가 필요 없어서 시스템 부팅 시 자동으로 실행되지 않아요. Windows 컨테이너나 Hyper-V Linux 컨테이너로 전환하거나 Win32 hosts 파일에서 host.docker.internal, gateway.docker.internal을 유지하도록 선택하면, 서비스 시작을 수락하는 UAC 프롬프트가 나타나요. 수락하면 서비스가 시작되고 다음 Windows 부팅 시 자동 시작으로 설정돼요.

Linux VM 안에서 root로 실행되는 컨테이너

Linux Docker 데몬과 컨테이너는 Docker가 관리하는 최소한의 특수 목적 Linux VM에서 실행돼요. 이 VM은 불변이라 확장하거나 설치된 소프트웨어를 바꿀 수 없어요. 즉 컨테이너가 기본적으로 root로 실행되지만 VM을 변경할 수 없고 Windows 호스트 머신에 Administrator 접근을 부여하지 않아요. Linux VM은 보안 경계 역할을 하고 호스트의 어떤 리소스에 접근할 수 있는지 제한해요. 파일 공유는 user-space로 만든 파일 서버를 사용하고, 호스트에서 바인드 마운트된 디렉터리는 원래 권한을 유지해요. 컨테이너는 명시적으로 공유된 파일 외의 호스트 파일에 접근할 수 없어요.

Enhanced Container Isolation

Docker Desktop은 Business 고객만 사용할 수 있는 Enhanced Container Isolation(ECI) 모드를 지원해서, 개발자 워크플로에 영향을 주지 않고 컨테이너를 더욱 보호해요. ECI는 모든 컨테이너를 자동으로 Linux user-namespace 안에서 실행해서, 컨테이너 안의 root가 Docker Desktop VM 안의 unprivileged 사용자로 매핑돼요.

Windows 컨테이너

경고: Windows 컨테이너 활성화는 중요한 보안 영향을 줘요. 참고: Windows 컨테이너는 all-users 설치 모드에서만 지원돼요. per-user 설치는 사용할 수 없어요.

Linux Docker Engine/컨테이너가 VM에서 실행되는 것과 달리, Windows 컨테이너는 운영체제 기능으로 구현되고 Windows 호스트에서 직접 실행돼요. 설치 중 Windows 컨테이너를 활성화하면, 컨테이너 안에서 관리를 위해 사용되는 ContainerAdministrator 사용자가 호스트 머신의 로컬 관리자가 돼요. 설치 중 Windows 컨테이너를 활성화하면 docker-users 그룹 멤버가 호스트에서 관리자로 승격할 수 있게 돼요. 개발자가 Windows 컨테이너를 실행하지 못하게 하려면 --no-windows-containers 설치 프로그램 플래그를 사용해 비활성화할 수 있어요.

네트워킹

네트워크 연결을 위해 Docker Desktop은 user-space 프로세스(vpnkit)를 사용하며, 이 프로세스는 실행한 사용자의 방화벽 규칙, VPN, HTTP 프록시 속성 같은 제약을 상속해요.

Windows 권한 요구 사항 이해하기