AWS, EKS에서 AI 에이전트 실행 환경 격리: Agent Sandbox와 gVisor 구성 가이드

조직 내 AI 에이전트 개발이 증가하면서, 검증되지 않은 코드가 공용 클러스터에서 실행되는 보안 위험이 대두되고 있다. 이를 해결하기 위해 Amazon EKS와 Agent Sandbox, gVisor를 결합해 실행 환경을 격리하는 설계 원칙과 구성 방법을 제시한다.

Agent Sandbox의 구조와 리소스

Agent Sandbox는 Kubernetes SIG Apps가 관리하는 오픈소스 프로젝트로, AI 에이전트가 생성한 코드를 실행하는 격리 환경을 선언형으로 관리한다. 핵심은 Sandbox 커스텀 리소스를 통해 수명 주기를 컨트롤러가 관리하고, RuntimeClass를 통해 gVisor나 Kata Containers 같은 강한 격리 런타임을 지정하는 것이다.

주요 리소스 구성은 다음과 같다:

• Sandbox: 단일 Pod, headless Service, PVC의 수명 주기 관리
• SandboxTemplate: Pod 명세와 보안 기본값, NetworkPolicy 포함
• SandboxWarmPool: 미리 띄워 둔 대기 Sandbox의 풀
• SandboxClaim: Warm Pool에서 Sandbox를 할당받는 요청

테스트 환경 및 설치 순서

테스트는 EKS 1.36 클러스터와 Agent Sandbox v1.0.5를 기반으로 진행되었다. gVisor 전용 노드 그룹을 생성하고 RuntimeClass를 등록한 뒤, VPC CNI의 NetworkPolicy를 활성화하는 순서로 설치가 이루어진다. sandbox-router는 Go 구현체로 배포되며, 요청을 해당 Sandbox Pod로 전달하는 리버스 프록시 역할을 수행한다.

격리 효과 및 성능 비교

runc 샌드박스와 gVisor 샌드박스를 동일한 보안 점검과 성능 측정으로 비교한 결과, gVisor는 호스트 커널 접근을 중재하고 파일 시스템 노출을 줄인다. kubectl port-forward가 실패하는 현상은 gVisor의 사용자 공간 커널 구조(Sentry)로 인해 호스트 쪽에 연결 소켓이 없기 때문이며, 이는 접근 통제가 아닌 구조적 특성으로 router를 통해 우회 가능하다.

신뢰할 수 없는 코드 실행 시 Pod Security 설정과 컨트롤러 기본값이 대부분의 위협을 차단하며, gVisor는 추가적인 커널 격리 계층으로 공격 표면을 최소화한다. 2부에서는 NetworkPolicy, DNS, Warm Pool 운영 및 격리 비용 최적화 방안을 다룬다.