Enhanced Container Isolation 제한 사항

Enhanced Container Isolation 제한 사항 (Enhanced Container Isolation limitations)

ECI가 가진 플랫폼별 제한과 기능 제약을 이해해 보안 전략을 계획하는 방법을 배워볼게요.

출처: 문서

본문

Enhanced Container Isolation은 일부 플랫폼별 제한과 기능 제약이 있어요. 이러한 제한을 이해하면 보안 전략을 계획하고 적절한 기대치를 설정하는 데 도움이 돼요.

WSL 2 보안 고려 사항

참고: Docker Desktop에는 WSL 2 버전 2.1.5 이상이 필요해요. WSL 2 백엔드의 ECI는 최소 6.3.0의 Linux 커널 버전에 의존하므로 WSL 버전 2.6 이상이 필요해요. wsl --version으로 버전을 확인하고 필요하면 wsl --update로 업데이트해요.

Enhanced Container Isolation은 Windows 백엔드 구성에 따라 다른 보안 수준을 제공해요. 다음 표는 WSL 2와 Hyper-V에서의 ECI를 비교해요:

보안 기능 WSL에서의 ECI Hyper-V에서의 ECI 설명
강력하게 안전한 컨테이너 예 예 악성 컨테이너 워크로드가 Docker Desktop Linux VM과 호스트를 침해하기 어렵게 함
사용자 접근으로부터 Docker Desktop Linux VM 보호 아니요 예 WSL에서는 사용자가 Docker Engine에 직접 접근하거나 Docker Desktop 보안 설정을 우회할 수 있음
Docker Desktop Linux VM이 전용 커널 보유 아니요 예 WSL에서는 Docker Desktop이 커널 수준 구성의 무결성을 보장할 수 없음

WSL 2 보안 격차:

  • 직접 VM 접근: 사용자가 VM에 직접 접근해(wsl -d docker-desktop) Docker Desktop 보안을 우회할 수 있어요. 이는 사용자에게 Docker Engine 설정을 수정하고 Settings Management 구성을 우회하는 root 접근 권한을 줘요.
  • 공유 커널 취약점: 모든 WSL 2 배포판은 같은 Linux 커널 인스턴스를 공유해요. 다른 WSL 배포판이 Docker Desktop의 보안에 영향을 주는 커널 설정을 수정할 수 있어요.

권장 사항

최대 보안을 위해 Hyper-V 백엔드를 사용해요. WSL 2는 더 나은 성능과 리소스 활용을 제공하지만 보안 격리는 감소해요.

Windows 컨테이너 미지원

ECI는 Linux 컨테이너(Docker Desktop의 기본 모드)에서만 작동해요. 네이티브 Windows 컨테이너 모드는 지원되지 않아요.

Docker Build 보호는 다양함

Docker Build 보호는 드라이버와 Docker Desktop 버전에 따라 달라요:

빌드 드라이버 보호 버전 요구 사항
docker (기본) 보호됨 Docker Desktop 4.30 이상 (WSL 2 제외)
docker (레거시) 보호되지 않음 Docker Desktop 4.30 이전 버전
docker-container 항상 보호됨 모든 Docker Desktop 버전

다음 Docker Build 기능은 ECI에서 작동하지 않아요:

  • docker build --network=host
  • Docker Buildx 자격(entitlements): network.host, security.insecure

권장 사항

이러한 기능이 필요한 빌드에는 docker-container 빌드 드라이버를 사용해요:

$ docker buildx create --driver docker-container --use
$ docker buildx build --network=host .

Kubeadm 모드의 Docker Desktop Kubernetes는 보호되지 않음

통합 Kubernetes 기능을 레거시 Kubeadm 프로비저너로 사용하면 ECI 보호의 혜택을 받지 못해요. 악성 또는 특권 파드가 Docker Desktop VM을 침해하고 보안 제어를 우회할 수 있어요.

권장 사항

Docker Desktop Kubernetes kind 프로비저너를 사용해요. 이 모드에서 ECI를 켜면 각 Kubernetes 노드가 ECI 보호 컨테이너에서 실행되어 Docker Desktop VM으로부터 더 강한 격리를 제공해요. kind 프로비저너는 더 빠르고 다중 노드 Kubernetes 클러스터를 지원해요.

보호되지 않는 컨테이너 유형

이러한 컨테이너 유형은 현재 ECI 보호의 혜택을 받지 못해요:

  • Docker Extensions: 확장 컨테이너가 ECI 보호 없이 실행됨
  • Kubernetes 파드: 이전 Kubeadm 프로비저너로 Docker Desktop의 통합 Kubernetes를 사용할 때

권장 사항

보안에 민감한 환경에서는 신뢰할 수 있는 소스의 확장 프로그램만 사용해요.

전역 명령 제한

명령 목록은 Docker 소켓을 마운트할 수 있는 모든 컨테이너에 적용돼요. 컨테이너 이미지별로 다른 명령 제한을 구성할 수 없어요.

로컬 전용 이미지 미지원

로컬에만 있는 임의의 이미지(레지스트리에 없는 이미지)는 다음 경우가 아니라면 Docker 소켓을 마운트할 수 없어요:

  • 허용된 기본 이미지에서 파생됨 (allowDerivedImages: true)
  • 와일드카드 허용 목록("*", Docker Desktop 4.36 이상) 사용

지원되지 않는 Docker 명령

이러한 Docker 명령은 아직 명령 목록 제한에서 지원되지 않아요:

  • compose: Docker Compose 명령
  • dev: 개발 환경 명령
  • extension: Docker Extensions 관리
  • feedback: Docker 피드백 제출
  • init: Docker 초기화 명령
  • manifest: 이미지 매니페스트 관리
  • plugin: 플러그인 관리
  • sbom: SBOM(소프트웨어 자재 명세서)
  • scout: Docker Scout 명령
  • trust: 이미지 신뢰 관리

성능 고려 사항

파생 이미지 영향

allowDerivedImages: true를 활성화하면 이미지 검증을 위해 컨테이너 시작 시간에 약 1초가 추가돼요.

레지스트리 의존성

  • Docker Desktop은 검증을 위해 레지스트리에서 이미지 digest를 주기적으로 가져와요
  • 초기 컨테이너 시작에는 허용 이미지를 검증하기 위해 레지스트리 접근이 필요해요
  • 네트워크 연결 문제는 컨테이너 시작 지연을 유발할 수 있어요

이미지 digest 검증

허용 이미지가 레지스트리에서 업데이트되면 로컬 이미지를 새로 고칠 때까지 로컬 컨테이너가 예기치 않게 차단될 수 있어요:

$ docker image rm <image>
$ docker pull <image>

프로덕션 호환성

컨테이너 동작 차이

대부분의 컨테이너는 ECI 유무와 관계없이 동일하게 실행돼요. 그러나 일부 고급 워크로드는 다르게 동작할 수 있어요:

  • 커널 모듈 로딩이 필요한 컨테이너
  • 전역 커널 설정(BPF, sysctl)을 수정하는 워크로드
  • 특정 권한 상승 동작을 기대하는 애플리케이션
  • 직접 하드웨어 장치 접근이 필요한 도구

프로덕션 배포 전에 개발 환경에서 ECI로 고급 워크로드를 테스트해 호환성을 확인해요.

런타임 고려 사항

Sysbox 런타임(ECI 사용)을 사용하는 컨테이너는 프로덕션에서 표준 OCI runc 런타임과 미묘한 차이가 있을 수 있어요. 이러한 차이는 일반적으로 특권 또는 시스템 수준 작업에만 영향을 줘요.

더 알아보기 (Learn more)