권한이 있는 홈 서비스에는 Docker 앱 컨테이너와 전용 LXC 중 어느 쪽이 위험을 더 잘 억제할까요?

서비스가 이미지로 배포되고 좁게 매핑된 파일, 포트, 장치, 기능만 필요하다면 최소 권한의 Docker 컨테이너를 선택하세요. 서비스에 더 완전한 Linux 환경, 직접적인 시스템 통합, 또는 별도로 관리되는 하나의 게스트 안에서 함께 실행되는 여러 관련 프로세스가 필요하다면 전용 비특권 LXC를 선택하세요. 광범위한 호스트 디렉터리, Docker 소켓, 제한 없는 장치 또는 호스트 수준의 루트 권한을 노출한 후에는 어느 모델도 의미 있는 보안 경계로 유지되지 않습니다.

먼저 동등한 배포 경계를 비교하기

Docker와 LXC는 모두 호스트 커널을 공유하는 Linux 컨테이너 기술이지만, 일반적으로 서로 다른 단위를 패키징합니다. Docker는 보통 하나의 애플리케이션 또는 Compose 스택을 격리합니다. LXC는 자체 사용자, 패키지 데이터베이스, 서비스, 운영 체제 파일 시스템을 갖춘 경량 시스템 컨테이너를 만듭니다.

따라서 공정한 비교 대상은 Linux 호스트에서 직접 실행되는 Docker 애플리케이션과, 동일한 특권 홈 서비스를 전용 LXC 내부에 설치하는 경우입니다. Docker를 LXC 내부에서 실행하는 방식과 LXC 자체를 비교하는 것이 아니며, 어느 컨테이너 모델과 별도의 커널을 사용하는 가상 머신을 비교하는 것도 아닙니다.

기존 ZimaSpace의 LXC 내부 Docker와 네이티브 설치 비교에서는 패키징과 유지 관리를 다룹니다. 이 글에서는 서비스가 일반적인 컨테이너 경계를 약화시키는 권한을 요청할 때의 보안 선택에 초점을 맞춥니다.

서비스에 필요한 정확한 권한으로 시작하기

“특권 홈 서비스”는 서로 관련 없는 여러 권한을 의미할 수 있습니다. USB 직렬 장치 읽기, GPU 렌더 노드 사용, 네트워크 인터페이스 제어, 파일 시스템 마운트, 낮은 포트에 바인딩, Bluetooth 액세스, SMART 데이터 읽기, 또는 다른 컨테이너 관리 등이 그 예입니다. 이러한 권한이 호스트에 미치는 위험은 서로 동일하지 않습니다.

서비스가 작동하도록 만드는 데 필요한 최소한의 기능, 장치, 경로 및 네트워크 모드만 허용하세요. Snyk의 특권 컨테이너 모드 설명은 완전한 특권 액세스가 모든 호스트 장치와 호스트에 거의 준하는 권한을 노출한다고 강조합니다. 이는 누락된 단일 권한을 조사하는 대신 사용해서는 안 됩니다.

서비스에 필요한 것이 /dev/dri/renderD128하나의 ID 기반 직렬 경로, 또는 하나의 읽기 전용 구성 디렉터리만 필요한 경우 Docker와 LXC 모두 해당 제한된 리소스를 노출할 수 있습니다. 배포에 광범위한 기능이나 여러 호스트 표면이 필요할 때 보안상의 차이가 중요해집니다.

비특권 LXC는 더 강력한 root 매핑 경계를 만듭니다

비특권 LXC에서는 게스트 내부의 UID 0이 Proxmox 호스트의 일반적인 보조 UID로 매핑됩니다. 프로세스는 컨테이너 내부에서는 root로 보일 수 있지만, 사용자 네임스페이스 외부에서는 호스트 root ID를 갖지 않습니다. 이를 통해 많은 파일 권한 실수와 일부 컨테이너 탈출이 초래하는 영향을 줄일 수 있습니다.

Linux Containers 프로젝트는 비특권 LXC의 root 매핑을 이 설계의 주요 보안 경계로 설명하며, AppArmor, seccomp, 기능 제한이 프로세스와 호스트 리소스에 추가적인 제약을 적용한다고 설명합니다.

이점은 컨테이너를 비특권으로 유지할 때 얻을 수 있습니다. 특권 LXC는 동일한 UID 매핑을 사용하지 않으므로 게스트 내부의 root가 호스트의 root에 훨씬 직접적으로 대응합니다. 마운트나 장치를 단순화하기 위해서만 특권 모드로 전환하면 LXC가 더 안전해 보였던 이유가 사라질 수 있습니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Docker는 애플리케이션을 LXC로 옮기지 않고도 root 위험을 줄일 수 있습니다

Docker 컨테이너는 제한 없이 실행되는 root 권한 데몬과 root 애플리케이션 사용자로 실행할 필요가 없습니다. 컨테이너 이미지는 비-root 사용자를 지정할 수 있고, 런타임은 기능을 제거할 수 있으며, 파일 시스템을 읽기 전용으로 설정할 수 있고, 사용자 네임스페이스를 통해 컨테이너 ID를 다시 매핑할 수 있습니다.

Docker의 rootless 모드는 호스트 root 권한 없이 데몬과 컨테이너를 모두 실행합니다. 애플리케이션과 필요한 스토리지 또는 네트워킹 기능이 rootless의 제한을 지원한다면 데몬과 런타임 위험을 줄일 수 있습니다.

애플리케이션이 이미 잘 패키징되어 있고 범위가 좁게 정의된 권한 하나만 필요하다면 Docker가 여전히 더 나은 경계입니다. 이를 완전한 LXC로 옮기면 침해된 애플리케이션에 매핑되는 리소스가 자동으로 줄어들지 않으면서 패치해야 할 운영 체제가 하나 더 추가됩니다.

Docker 소켓은 애플리케이션 경계를 무너뜨릴 수 있습니다

일부 대시보드, 자동 업데이트 도구, 백업 도구 및 모니터링 서비스는 다음에 대한 액세스를 요청합니다. /var/run/docker.sock. 이 소켓을 사용하면 클라이언트가 호스트 Docker 데몬에 컨테이너 생성, 호스트 경로 마운트, 장치 노출, 네트워크 변경을 지시할 수 있습니다. 따라서 침해된 서비스는 커널 탈출을 악용하지 않고도 간접적으로 호스트를 제어할 수 있습니다.

Netdata의 Docker 소켓 액세스가 호스트 관리처럼 작동하는 이유에 대한 분석은 다음과 같이 설명합니다. 프로세스는 일반적인 컨테이너 탈출 없이 권한이 높은 데몬에 요청하여 강력한 호스트 작업을 대신 수행하게 합니다.

여기가 첫 번째 중단 경계입니다. 서비스에 제한 없는 Docker 소켓 액세스가 필요하다면 일반적인 Docker 격리와 일반적인 LXC 격리를 비교하는 것은 오해의 소지가 있습니다. 해당 서비스를 호스트 관리자처럼 취급하고, 가능하다면 목적에 맞게 설계된 프록시를 통해 API를 제한하며, 신뢰할 수 없는 네트워크와 격리하고, 자격 증명을 적절히 보호하세요.

장치 매핑에서는 권한 계층이 더 적은 모델이 유리합니다

GPU, USB 코디네이터, 튜너, Coral 가속기, UPS 또는 직렬 어댑터는 어느 배포 방식으로든 전달할 수 있습니다. 직접 Docker를 사용하는 경우 호스트가 장치를 애플리케이션 컨테이너에 노출합니다. LXC에서는 Proxmox가 장치를 시스템 컨테이너에 노출하고, 해당 컨테이너가 서비스를 네이티브로 실행하거나 중첩된 Docker에 다시 전달할 수 있습니다.

여러 관련 프로세스가 동일한 장치를 사용하고 Linux 사용자 또는 그룹이 액세스를 관리해야 한다면 전용 LXC가 더 깔끔할 수 있습니다. 하나의 이미지가 하나의 장치만 필요하고 매핑이 Compose에 직접 설명되어 있다면 Docker가 더 깔끔할 수 있습니다.

어느 컨테이너든 장치 하나의 권한을 설정하기 어렵다는 이유만으로 모든 장치를 제공하지 마세요. Proxmox는 LXC 보안이 네임스페이스, AppArmor, seccomp 및 장치 제한을 결합한다고 설명합니다. 광범위한 장치 액세스는 Docker 완전 권한 모드와 마찬가지로 이러한 다층 경계의 일부를 제거합니다.

호스트 바인드 마운트는 서로 다른 방향으로 위험을 이전합니다

Docker 바인드 마운트는 선택한 호스트 경로를 애플리케이션에 직접 노출합니다. 사진, 백업, 구성 또는 다른 애플리케이션의 상태 데이터가 포함된 쓰기 가능한 마운트는 침해된 컨테이너에 해당 경로에서 매핑된 호스트 사용자가 가진 것과 동일한 수정 권한을 부여합니다.

LXC 바인드 마운트는 해당 경로를 게스트에 노출하며, 게스트 내 여러 서비스와 관리 사용자가 UID 및 GID 매핑에 따라 액세스할 수 있습니다. 추가적인 시스템 경계는 권한을 체계적으로 관리하는 데 도움이 될 수 있지만, 동시에 게스트 내부에서 데이터에 접근할 수 있는 프로세스의 범위도 넓힙니다.

가능한 경우 읽기 전용 마운트를 사용하고, 구성과 대용량 데이터를 분리하며, 호스트 루트 디렉터리를 매핑하지 마세요. /proc, /sys, /dev또는 Docker 데이터 디렉터리에 광범위하게 적용됩니다. 서비스가 보호된 NAS 데이터를 다시 작성해야 한다면 애플리케이션 격리만으로는 스냅샷과 독립적인 백업을 대신할 수 없습니다.

네트워크 권한은 파일 시스템 액세스보다 더 큰 피해 범위를 만들 수 있습니다

VPN 게이트웨이, DNS 필터, 네트워크 검색 도구, Home Assistant 통합 기능, 모니터링 시스템과 같은 홈 서비스는 호스트 네트워킹, raw 소켓, 패킷 캡처, 방화벽 수정 또는 여러 VLAN에 대한 액세스를 요청할 수 있습니다. 이러한 기능은 트래픽을 노출하고 서비스가 다른 장치에 영향을 미치도록 할 수 있습니다.

호스트 네트워킹을 사용하는 Docker 컨테이너는 포트 수준의 네트워크 분리를 잃게 되며, 다음과 같은 추가 기능이 있으면 NET_ADMIN 또는 NET_RAW 침해가 발생했을 때 가능한 작업의 범위를 넓힐 수 있습니다. 자체 가상 인터페이스를 사용하는 LXC는 별도의 주소와 방화벽 정책을 제공할 수 있지만, 완전한 권한을 가진 게스트나 광범위하게 브리지된 게스트는 여전히 민감한 네트워크에 접근할 수 있습니다.

가장 좁은 네트워크 경로를 정의할 수 있는 경계를 선택하세요. 별도의 VLAN, 전용 주소, 명시적인 방화벽 규칙, NAS 관리 기능에 대한 액세스 차단은 서비스를 신뢰할 수 있는 모든 네트워크에 그대로 연결해 둔 채 컨테이너 기술만 바꾸는 것보다 위험을 줄이는 데 더 효과적인 경우가 많습니다.

완전한 권한의 LXC와 완전한 권한의 Docker는 서로 다른 방식으로 실패합니다

완전한 권한의 Docker 컨테이너는 루트 권한으로 실행되는 Docker 데몬을 통해 광범위한 Linux 기능과 장치 액세스 권한을 받습니다. 완전한 권한의 LXC는 전체 게스트 사용자 공간이 호스트 루트와 훨씬 더 밀접한 정체성 관계를 갖게 합니다. 둘 다 일반적인 비특권 애플리케이션 컨테이너처럼 취급해서는 안 됩니다.

Tigera의 보안 지침은 권한이 있는 Docker 모드가 주요 격리 제어를 우회한다고 경고합니다. Proxmox 커뮤니티 토론에서도 LXC 내부에서 중첩 또는 광범위한 호스트 파일 시스템 접근을 활성화하면 부주의하게 구성할 경우 호스트 /proc 및 /sys 영역이 노출될 수 있다고 경고합니다.

서비스에 실제로 호스트 root와 동등한 권한이 필요하다면, 전용 커널을 사용하는 VM이 더 명확한 격리 경계를 제공할 수 있습니다. 서비스가 인터넷에 노출되거나, 신뢰할 수 없는 입력을 처리하거나, 커널에 인접한 드라이버를 로드하거나, 다른 워크로드를 관리하는 경우 추가 메모리와 스토리지 오버헤드를 감수할 만합니다.

업데이트와 복구가 격리를 계속 사용할 수 있는지 결정합니다

Docker를 사용하면 애플리케이션 패키지를 교체할 수 있습니다. 고정된 이미지 또는 다이제스트에서 컨테이너를 다시 만들고, 구성과 영구 데이터를 복원한 다음, 동일한 최소 권한을 다시 적용합니다. 보안 정책이 셸 명령을 기억해 두는 방식이 아니라 Compose에 명시되어 있을 때 특히 유용합니다.

전용 LXC를 사용하면 운영 환경 전체를 하나의 Proxmox 게스트로 교체할 수 있습니다. 패키지 데이터베이스, 서비스 파일, 사용자 및 장치 매핑을 함께 백업할 수 있습니다. 바인드 마운트, UID 매핑, 호스트 장치 및 네트워크 규칙이 게스트 외부에 문서화되어 있으면 복구가 깔끔하게 이루어집니다.

ZimaSpace의 Docker VM 및 앱별 LXC 복구 경계 비교는 이와 연관된 운영 테스트를 제공합니다. 더 작은 보안 경계는 광범위한 권한을 수동으로 다시 만들지 않고 복원할 수 있을 때만 유용합니다.

Docker 또는 LXC를 선택하기 전에 권한 축소 테스트를 실행하세요

1. 서비스가 요청하는 모든 장치, 호스트 경로, 기능, 네트워크, API, 커널 기능을 나열합니다.
2. 전체 권한 모드를 제거하고, 필요한 권한을 한 번에 하나씩 다시 추가합니다.
3. 애플리케이션을 비root 사용자로 실행하거나, 지원되는 경우 권한 없는 LXC 내부에서 실행합니다.
4. 범위가 넓은 쓰기 가능 마운트를 제한된 읽기 전용 경로 또는 데이터 세트별 경로로 교체합니다.
5. Docker 소켓 접근을 제거하거나 서비스와 데몬 사이에 제한된 프록시를 둡니다.
6. 어떤 호스트 파일, 장치, 네트워크에 여전히 접근할 수 있는지 확인하여 침해 가정을 검증합니다.
7. 버전이 지정된 구성만 사용하여 깨끗한 Docker 또는 LXC 호스트에서 서비스를 복원합니다.

보안을 단순히 계층 수로만 평가하지 마세요. 필요한 모든 디바이스, 마운트, capability, 소켓 및 네트워크를 추가한 후 사용할 수 있는 실질적인 권한을 기준으로 평가하세요. 액세스 범위가 좁은 단순한 컨테이너가 여러 예외가 있는 복잡한 중첩 설계보다 안전할 수 있습니다.

특권 홈 서비스에 적합한 경계는 무엇인가요?

Docker 애플리케이션 컨테이너를 선택해야 할 때

서비스가 이미지로 배포되고 명시적인 디바이스 또는 마운트 한두 개가 필요하며 다음 없이 실행할 수 있다면 Docker를 선택하세요: --privileged, 제한 없는 Docker 소켓 액세스 또는 광범위한 호스트 네트워킹. 버전을 고정하고 capability를 제거하며 가능한 경우 파일 시스템을 읽기 전용으로 사용하고 영구 데이터를 명시적으로 관리하세요.

전용 비특권 LXC를 선택해야 할 때

서비스에 더 완전한 Linux 환경, 여러 관련 데몬, 직접적인 systemd 통합 또는 복잡한 디바이스 그룹 권한이 필요하다면 LXC를 선택하세요. 사용자 네임스페이스 매핑을 유지하고 AppArmor 및 seccomp 제한을 활성화하며 모든 호스트 마운트와 디바이스 매핑을 문서화하세요.

대신 VM을 선택해야 할 때

워크로드에 호스트 root와 동등한 제어 권한이 필요하거나, 일반적이지 않은 드라이버를 로드하거나, 다른 워크로드를 관리하거나, 신뢰할 수 없는 공개 입력을 받거나, 광범위한 파일 시스템 및 네트워크 권한 없이는 실행할 수 없다면 VM을 사용하세요. 별도의 커널은 공유 커널 컨테이너에 예외를 더 추가하는 것보다 강력한 경계를 만듭니다.

FAQ

특권 LXC가 특권 Docker 컨테이너보다 안전한가요?

일반적인 규칙으로는 그렇지 않습니다. 둘 다 중요한 격리 제어 기능을 약화시키지만 권한을 노출하는 방식은 다릅니다. 컨테이너라는 명칭에 의존하지 말고 UID 매핑, 디바이스, 마운트, capability, 네트워크 액세스, AppArmor, seccomp 및 데몬 API를 평가하세요.

비특권 LXC 안에서 Docker를 실행하면 보안 계층이 하나 더 추가되나요?

LXC와 Proxmox 호스트 사이에 UID 매핑을 추가할 수 있지만, 중첩 Docker에는 nesting 기능, 추가 capability, 파일 시스템 예외 또는 디바이스 매핑이 필요할 수 있습니다. 이러한 변경은 이점을 상쇄할 수 있습니다. 호스트와의 강력한 분리가 필요하다면 VM이 더 명확한 선택입니다.

LAN 전용 홈 서비스에도 비특권 컨테이너가 필요한가요?

다른 LAN 장치, 취약한 웹 인터페이스, 악성 미디어 또는 문서 입력, 공급망 이미지 또는 노출된 자격 증명을 통해 침해가 발생할 수 있다면 그렇습니다. LAN 전용으로 배치하면 일부 노출은 줄어들지만 호스트 root 액세스가 무해해지는 것은 아닙니다.

최종 결론

패키지로 제공되는 애플리케이션이 권한을 엄격하게 선언하고 호스트의 관리 인터페이스 없이 실행될 수 있다면 Docker를 사용하세요. 서비스에 더 완전한 Linux 시스템이 필요하지만 root 매핑과 제어된 디바이스 액세스는 유지하려면 비특권 LXC를 사용하세요. 어느 설계든 광범위한 호스트 root 권한, 제한 없는 소켓 또는 중요한 데이터에 대한 쓰기 액세스가 필요하다면 컨테이너 간 비교를 중단하고 더 강력한 VM 또는 별도 시스템 경계 뒤에 서비스를 배치하세요.