1부에서는 Kubernetes SIG Apps의 Agent Sandbox v1.0.5를 Amazon EKS 1.36 클러스터에 gVisor와 함께 구성하고, 신뢰할 수 없는 코드를 막는 4개 격리 계층을 구성한 뒤, 그중 Pod 보안 설정과 gVisor 계층을 확인했습니다.
나머지 NetworkPolicy와 전용 노드 그룹의 IMDS 설정은 2부 1파트에서 확인합니다. 2부에서는 이 구성을 운영 환경에 올릴 때 확인해야 할 내용을 다룹니다. NetworkPolicy와 DNS 경로, Warm Pool과 Pod IP, gVisor의 성능 비용, 샌드박스 수명 주기, 그리고 에이전트 연동과 sandbox-router 보안입니다.
테스트 환경은 1부와 같습니다. EKS 1.36 클러스터에 gVisor 전용 노드 그룹(m7i.xlarge × 2)을 추가하고, Agent Sandbox 컨트롤러와 Go 구현의 sandbox-router를 설치한 상태에서 runc 샌드박스와 gVisor 샌드박스를 비교했습니다.
시리즈 블로그 보기
AWS에서 AI 에이전트 실행 환경 격리하기 1부: Amazon EKS와 Agent Sandbox, 개념과 구성
AWS에서 AI 에이전트 실행 환경 격리하기 2부: Amazon EKS와 Agent Sandbox, 개념과 구성
1. NetworkPolicy는 활성화해야 동작합니다
SandboxTemplate은 사용자가 정책을 지정하지 않으면 보안 기본 정책을 만듭니다. Ingress는 agent-sandbox-system 네임스페이스의 sandbox-router에서 오는 트래픽만 허용하고 Egress는 0.0.0.0/0에서 RFC 1918 사설 대역과 169.254.0.0/16을 뺀 Public IP로만 나갈 수 있습니다. 이 정책이 실제로 동작하는지 샌드박스 안에서 여러 목적지로 TCP 연결을 시도해 확인했습니다.
목적지
활성화 전
활성화 후
AWS API Public Endpoint (443)
연결됨
연결됨
인스턴스 메타데이터 서비스 (169.254.169.254)
연결됨
차단
Kubernetes API, CoreDNS, VPC DNS
연결됨
차단
다른 샌드박스 Pod, router Pod
연결됨
차단
다른 네임스페이스의 Pod에서 샌드박스로
연결됨
차단
sandbox-router를 거친 샌드박스 호출
HTTP 200
HTTP 200
표 1. 템플릿 관리형 NetworkPolicy의 VPC CNI 활성화 전후 연결 결과 (runc와 gVisor 결과 동일, TCP 3초 시도 기준)
그림 1은 활성화 후 샌드박스 Pod를 기준으로 허용 경로와 차단 경로를 정리한 것입니다. DNS와 VPC 엔드포인트 경로는 이어지는 Route 53 Resolver 파트에서 다룹니다.
그림 1. 샌드박스 Pod에 적용된 NetworkPolicy의 허용 경로와 차단 경로 (VPC CNI 활성화 후, runc와 gVisor 결과 동일)
활성화 전에는 NetworkPolicy 객체가 있었는데도 샌드박스가 메타데이터 서비스와 Kubernetes API에 그대로 연결됐습니다. 정책을 노드 규칙으로 바꾸는 PolicyEndpoint가 하나도 없었기 때문입니다. 활성화 후에는 같은 정책이 문서대로 동작했고 gVisor Pod에도 동일하게 적용됐습니다. gVisor는 사용자 공간 네트워크 스택을 사용하지만 패킷은 결국 Pod의 네트워크 인터페이스를 지나고 VPC CNI는 노드에서 eBPF로 정책을 처리하므로 런타임과 관계없이 정책이 적용됩니다. 정책은 샌드박스 수와 상관없이 템플릿당 하나만 생성됐습니다.
EKS 문서의 주의 사항 하나는 검토가 필요합니다. VPC CNI의 기본 standard 모드에서는 새 Pod가 정책이 적용되기 전