Docker의 비공개 MicroVM API 역공학: 보안 에이전트 실행
AI 코딩 에이전트인 Claude Code, Codex, Gemini와 같은 도구들의 부상은 중요한 보안 과제를 제기합니다: 자율 에이전트가 패키지를 설치하고 파일을 수정하며 임의의 코드를 실행하도록 허용하면서도 호스트 시스템을 손상시키지 않는 방법을 찾는 것입니다. Docker 컨테이너는 오랫동안 격리 표준이었지만, 신뢰할 수 없는 코드를 실행하는 데 근본적으로 부적합합니다.
최근 Docker는 "Docker Sandboxes"를 도입했으며, 여기에는 microVM을 생성하는 비공개 API가 포함되어 있습니다. 이 API를 역공학함으로써 개발자는 이제 코딩 에이전트와 기타 신뢰할 수 없는 워크로드를 위한 안전하고 격리된 환경을 조정할 수 있게 되었으며, 표준 컨테이너의 한계를 넘어설 수 있습니다.
컨테이너 vs. MicroVM: 보안 격차
Docker가 샌드박스 기능을 위해 microVM으로 전환한 이유를 이해하려면 컨테이너 격리와 가상 머신 격리를 구분해야 합니다.
Containers는 호스트의 커널을 공유합니다. 네임스페이스와 cgroup을 사용해 격리 레이어를 제공하지만, 커널이 공유되기 때문에 커널 취약점이 있으면 손상된 컨테이너가 호스트로 탈출할 수 있습니다. 이는 높은 권한으로 실행되는 다중 테넌트 플러그인이나 AI 에이전트에 위험한 선택이 됩니다.
MicroVMs는 반대로 각 인스턴스마다 별도의 커널을 제공합니다. 전체 가상 머신과 동일한 보안 프로파일을 제공하면서도 AWS Lambda나 Firecracker와 같은 기술처럼 속도와 낮은 오버헤드에 최적화되어 있습니다. 이는 신뢰할 수 없는 사용자 코드를 격리하는 데 금본위로 여겨집니다.
비교 요약
| 기능 | Docker 컨테이너 | Docker 샌드박스 (microVM) |
|---|---|---|
| 보안 | 공유 커널 (네임스페이스) | 분리된 커널 (microVM) |
| 신뢰할 수 없는 코드 | 안전하지 않음 | 안전함 |
| 네트워크 접근 | 직접 HTTP | 필터링 프록시를 통해 |
| 볼륨 | 직접 마운트 | 양방향 파일 동기화 |
| 플랫폼 | Linux, macOS, Windows | macOS, Windows 전용 (초기) |
비공개 API 해부
Docker의 샌드박스 기능은 sandboxd 데몬에 의해 관리되며, 이 데몬은 ~/.docker/sandboxes/sandboxd.sock에 있는 Unix 소켓을 청취합니다. 역공학을 통해 이 데몬이 세 가지 주요 엔드포인트를 제공한다는 것이 밝혀졌습니다:
GET /vm: 모든 활성 VM을 나열합니다.POST /vm: 새 VM을 생성합니다.DELETE /vm/{vm_name}: 특정 VM을 파괴합니다.
격리 아키텍처
표준 Docker와 가장 큰 차이점 중 하나는 데몬이 처리되는 방식입니다. 일반적인 설정에서는 모든 컨테이너가 /var/run/docker.sock을 공유합니다. 샌드박스 모델에서는 각 microVM이 자체 전용 Docker 데몬을 ~/.docker/sandboxes/vm/<name>/docker.sock에 배치합니다.
이를 통해 microVM 내부에서 실행되는 컨테이너는 호스트와 다른 VM으로부터 완전히 격리됩니다. 이러한 VM과 상호 작용하려면 개발자는 curl --unix-socket이나 docker --host unix://...을 사용해 Unix 소켓 경로를 재정의해야 합니다.
구현 세부 사항
이 VM들은 완전히 격리되어 있기 때문에 이미지는 수동으로 VM 환경에 로드해야 합니다. 프로세스는 이미지를 빌드하고, 아카이브한 뒤, VM 전용 소켓을 통해 로드하는 순서로 진행됩니다:
# Example workflow
docker save my-image | docker --host unix://$VM_SOCK load
네트워킹 및 볼륨
이 microVM들의 외부 트래픽은 host.docker.internal:3128에 있는 필터링 프록시를 통해 라우팅됩니다. 연결을 보장하려면 컨테이너에 특정 환경 변수(HTTP_PROXY와 HTTPS_PROXY)가 필요합니다. 프록시가 정책 적용을 위해 HTTPS에 대해 중간자 공격(MITM)을 수행하므로, 개발자는 VM 응답에 포함된 CA 인증서를 설치하거나 TLS 검증을 비활성화(NODE_TLS_REJECT_UNAUTHORIZED=0 등)해야 합니다.
워크스페이스 동기화는 절대 경로를 사용해 처리되므로, 볼륨 마운트가 기대대로 동작하여 호스트 파일과 격리된 환경 사이에 원활한 브리지를 제공합니다.
비판적 분석 및 커뮤니티 관점
역공학된 API가 에이전트 조정을 위한 강력한 원시 기능을 제공하지만, 커뮤니티는 그 유용성과 한계에 대해 여러 중요한 점을 제기했습니다.
플랫폼 가용성
초기 구현은 Apple Virtualization.framework와 Hyper‑V에 의존해 macOS와 Windows에만 제한되었습니다. 그러나 커뮤니티 구성원들은 Linux 지원이 KVM을 통해 가능하다고 지적했으며, Docker는 이후 Docker Desktop 없이도 동작하는 50 MB 크기의 독립 실행형 바이너리 sbx를 출시했습니다.
"에이전트 보안" 논쟁
일부 개발자는 VM 수준 격리가 AI 에이전트에 대한 주요 문제인지 의문을 제기합니다. 한 기여자는 다음과 같이 언급했습니다:
"심지어 샌드박스된 에이전트도 보통 많은 권한을 가지고 있습니다. 침해된 패키지를 설치해 코드에 백도어를 추가하거나, 일부 액세스 토큰을 악용해 피해를 주는 등 다양한 위험이 존재합니다."
이는 microVM이 호스트 커널 탈출을 방지하더라도, 자율 에이전트가 코드를 실행하면서 발생하는 고수준 애플리케이션 보안 위험을 해결하지 못한다는 점을 시사합니다.
결론
Docker가 microVM으로 전환한 것은 신뢰할 수 없는 코드 실행에 대한 산업적 시각이 변화하고 있음을 나타냅니다. 샌드박스당 전용 커널을 제공함으로써 Docker는 컨테이너의 "공유 커널" 위험에서 벗어나고 있습니다. API는 아직 비공개이며 변경될 수 있지만, 안전한 AI 코딩 어시스턴트와 다중 테넌트 SaaS 플러그인을 구축하기 위한 견고한 기반을 제공합니다.