Sandboxed Containers 정리: 보안 격리와 트레이드오프

글 요약

Sandboxed containers는 컨테이너와 호스트 OS 사이에 추가 격리 레이어를 두어, 호스트 커널과의 직접 접점을 줄이는 방식이다. 기존 컨테이너 구조에서 발생할 수 있는 container breakout 위험을 낮추는 데 초점이 있다.

대표 런타임은 다음과 같다.

• gVisor: 사용자 공간 커널(Sentry)이 syscall을 가로채 에뮬레이션
• Kata Containers: 컨테이너를 경량 VM에서 실행해 커널 분리

일반 컨테이너와의 차이

일반 컨테이너는 containerd, cri-o 같은 런타임을 통해 호스트 커널의 syscalls를 직접 사용한다. 성능에는 유리하지만, 커널 취약점이 있을 때 멀티테넌트 환경의 위험도가 커질 수 있다.

Sandboxed containers는 이 경로를 우회하거나 제한해 호스트 커널과의 직접 접점을 줄이는 것이 핵심이다.

gVisor vs Kata Containers

항목	gVisor	Kata Containers
격리 방식	사용자 공간 커널이 syscall을 가로채 처리	경량 VM 안에서 guest kernel 실행
호스트 커널 접근	간접(에뮬레이션)	간접(guest kernel 경유)
보안 모델	syscall mediation 기반 격리	하이퍼바이저 기반 VM 격리
성능 오버헤드	있음(케이스에 따라 편차 큼)	있음(대체로 더 큼)
시작 시간	일반 컨테이너보다 느림	일반 컨테이너보다 더 느린 편
운영 복잡도	상대적으로 낮음	상대적으로 높음
디버깅 난이도	중간	높음
잘 맞는 곳	격리 필요하지만 VM 수준은 부담인 워크로드	강한 격리가 꼭 필요한 워크로드

성능 트레이드오프

보안이 강화되는 대신, 사용자 공간 커널/가상화 오버헤드로 인해 CPU, 메모리 사용량 증가와 시작 지연이 발생할 수 있다. 글에서는 이러한 비용을 감수할 수 있는 환경에서 선택해야 한다고 언급한다.

사용 사례

원문에서 언급된 실제 사용 사례는 다음과 같다.

• OpenAI: gVisor로 고위험 워크로드 실행
• Cloudflare: 빌드 인프라에 gVisor 사용
• NVIDIA: Kata Containers로 AI/ML 워크로드 격리
• Blink: EKS Pod 보안 격리에 gVisor 활용

적용 권장 시나리오

글에서 제시하는 권장 사용 환경은 다음과 같다.

• CI/CD 플랫폼처럼 사용자가 임의 코드를 실행하는 환경
• Serverless/Function 서비스 (AWS Lambda, Cloud Run 등)
• SaaS 환경에서 고객 코드 실행

반대로 신뢰된 내부 마이크로서비스 환경에서는 성능 오버헤드가 더 크다고 판단될 수 있다.

참고

• 원문: https://devopscube.com/sandboxed-containers/