AI Briefing

Ray와 vLLM 멀티노드 배포, 인증 없는 제어 플레인 노출

Scaling frontier LLM inference across GPU nodes opens unauthenticated control-plane ports: our benchmark on Ray + vLLM on Kubernetes

·2026.09.29 18:47

핵심 내용

Ray와 vLLM 기본 설정이 인증 없는 제어 포트 노출로 크로스 네임스페이스 공격에 취약한 것으로 드러났다.

자세히 보기

AWS EKS 기반 멀티노드 분산 LLM 클러스터 보안 벤치마크에서 Ray, KubeRay, vLLM의 기본 구성에 심각한 취약점이 발견됐다. 연구 결과, 활성 리스닝 소켓 17개 중 15개가 컨테이너 매니페스트에 선언되지 않아, 다른 네임스페이스의 컨테이너가 인증되지 않은 평문 gRPC로 Ray GCS(포트 6379) 및 **raylet 워커 RPC(포트 10002–10006)**에 연결할 수 있었다. 또한 단일 GPU vLLM 배포 환경에서는 인증 없이 26개 API 라우트가 노출됐다.

스캐너 탐지 실패

Trivy, Checkov, Kubescape, kube-linter 등 표준 보안 도구는 이러한 런타임 노출을 탐지하지 못했다. 보고서는 스캐너가 RayCluster 커스텀 리소스를 검사할 수 없기 때문에 분산 AI 인프라 가시성에 치명적인 공백이 발생한다고 분석했다.

완화 조치의 성능 비용

벤치마크는 완화 전략과 추론 성능에 미치는 영향을 평가했다.

  • 네트워크 정책: Ingress 기본 거부 NetworkPolicy를 적용하면 Ray 제어 플레인에 대한 인접 포드 접근을 차단하면서도 측정 가능한 지연 시간 증가 없이 보안성을 확보할 수 있었다.
  • 트래픽 암호화: WireGuard(Cilium과 AWS VPC CNI 연동)를 사용해 노드 간 GPU 트래픽을 암호화하면 워크로드가 보호되지만 성능 오버헤드가 발생한다. 부하 조건에서 처리량은 3.4%~6.5% 감소하고 지연 시간은 3.2%~8.4% 증가했다.

이 한국어 요약은 AI가 자동으로 만들었습니다. 원문의 주장과 맥락은 원문에서 확인해 주세요. 저작권은 원저작자에게 있습니다.

AI 처리 방식을 확인하거나, 요약 오류와 출처 표기 문제, 삭제 요청을 문의 · 건의로 알려주세요.