Enhanced Container Isolation FAQ
Enhanced Container Isolation FAQ (Enhanced Container Isolation FAQs)
메인 문서에서 다루지 않는 Enhanced Container Isolation(ECI)에 대한 흔한 질문들의 답을 배워볼게요.
출처: 문서
본문
구독: Business 대상: 관리자
이 페이지는 메인 문서에서 다루지 않는 Enhanced Container Isolation(ECI)에 대한 흔한 질문에 답해요.
ECI를 켜면 Docker 사용 방식을 바꿔야 하나요?
아니요. ECI는 더 안전한 컨테이너를 만들어 백그라운드에서 자동으로 작동해요. 기존 Docker 명령, 워크플로우, 개발 도구를 변경 없이 계속 사용할 수 있어요.
모든 컨테이너 워크로드가 ECI에서 잘 작동하나요?
대부분의 컨테이너 워크로드는 ECI를 켜도 문제없이 실행돼요. 그러나 특정 커널 수준 접근이 필요한 일부 고급 워크로드는 작동하지 않을 수 있어요. 영향을 받는 워크로드에 대한 자세한 내용은 ECI limitations 문서를 참고해요.
--privileged 플래그 사용을 제한하면 안 되나요?
특권(privileged) 컨테이너는 Docker-in-Docker, Kubernetes-in-Docker, 하드웨어 장치 접근 같은 정당한 목적을 제공해요. ECI는 이러한 고급 워크로드가 안전하게 실행되면서 Docker Desktop VM을 침해하지 못하게 하는 더 나은 솔루션을 제공해요.
ECI가 컨테이너 성능에 영향을 주나요?
ECI는 컨테이너 성능에 최소한의 영향을 줘요. 유일한 예외는 보안을 위해 Sysbox 런타임이 검사하는 많은 mount와 umount 시스템 호출을 수행하는 컨테이너예요. 대부분의 개발 워크로드는 눈에 띄는 성능 차이를 보지 못해요.
ECI를 켜면 컨테이너 런타임을 오버라이드할 수 있나요?
아니요. ECI를 켜면 모든 컨테이너가 어떤 --runtime 플래그와 무관하게 Sysbox 런타임을 사용해요:
$ docker run --runtime=runc alpine echo "test"
# 이것은 여전히 runc가 아닌 sysbox-runc를 사용함
--runtime 플래그는 Docker Desktop VM에서 컨테이너를 실제 root로 실행해 ECI 보안을 우회하지 못하도록 무시돼요.
ECI는 켜기 전에 만든 컨테이너를 보호하나요?
아니요. ECI는 켠 후에 만든 컨테이너만 보호해요. ECI를 켜기 전에 기존 컨테이너를 제거해요:
$ docker stop $(docker ps -q)
$ docker rm $(docker ps -aq)
자세한 내용은 Enable Enhanced Container Isolation 문서를 참고해요.
ECI는 어떤 컨테이너를 보호하나요?
ECI 보호는 컨테이너 유형과 Docker Desktop 버전에 따라 달라요.
항상 보호
docker run과docker create로 만든 컨테이너docker-container빌드 드라이버를 사용하는 컨테이너kind프로비저너를 사용하는 Kubernetes
플랫폼에 따라 다름
- Docker Build: Mac, Linux, Hyper-V 백엔드의 Windows용 Docker Desktop에서 보호
보호되지 않음
- Docker Extensions
- Docker Debug 컨테이너
kubeadm프로비저너를 사용하는 Kubernetes
자세한 내용은 ECI limitations 문서를 참고해요.
ECI를 켜면 Docker 소켓을 마운트할 수 있나요?
기본적으로 아니요. ECI는 보안을 위해 Docker 소켓 바인드 마운트를 차단해요. 그러나 Testcontainers 같은 신뢰할 수 있는 이미지에 대한 예외를 구성할 수 있어요. 구성 세부 사항은 Configure Docker socket exceptions 문서를 참고해요.
ECI가 제한하는 바인드 마운트는 무엇인가요?
ECI는 Docker Desktop VM 디렉터리의 바인드 마운트를 제한하지만, Docker Desktop Settings에서 구성한 호스트 디렉터리 마운트는 허용해요.