글 요약
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 환경에서 고객 코드 실행
반대로 신뢰된 내부 마이크로서비스 환경에서는 성능 오버헤드가 더 크다고 판단될 수 있다.