네임스페이스 방벽을 깨다 쿠버네티스 오퍼레이터 교차 네임스페이스 참조 취약점 분석

초록

쿠버네티스 오퍼레이터가 선언된 네임스페이스 범위와 실제 로직이 수행하는 범위가 일치하지 않을 때 발생하는 교차‑네임스페이스 참조 취약점을 규명한다. 공격자는 자신이 허가받은 단일 네임스페이스만 접근 가능하더라도 오퍼레이터를 이용해 다른 네임스페이스의 리소스를 조작하고 권한을 상승시킬 수 있다. 저자들은 정적 분석 도구를 구축해 2 268개의 오퍼레이터 중 14 % 이상이 취약할 가능성이 있음을 확인했으며, 8건의 취약이 확인·CV​E가 부여된 실증적 영향을 보고한다.

상세 분석

이 논문은 쿠버네티스 오퍼레이터가 “선언된 스코프(네임스페이스‑스코프)와 구현된 스코프(클러스터‑스코프)” 사이에 존재하는 불일치를 핵심 원인으로 규정한다. 오퍼레이터는 CRD(커스텀 리소스 정의)를 통해 사용자에게 네임스페이스‑스코프 리소스를 생성하도록 허용하지만, 내부 컨트롤러 로직은 종종 클러스터‑스코프 API(예: 다른 네임스페이스의 Secret, RoleBinding, ClusterRole 등)를 호출한다. RBAC는 네임스페이스‑레벨 권한만 부여받은 서비스 어카운트가 이러한 클러스터‑스코프 API를 호출할 수 없도록 설계됐지만, 오퍼레이터가 “스코프 미스매치”를 가지고 있으면 RBAC 검증을 우회한다.

논문은 두 가지 공격 전략을 제시한다. 첫 번째는 “리소스 인젝션”으로, 공격자는 자신이 관리하는 네임스페이스에 악의적인 CR을 배포하고, 오퍼레이터가 이를 처리하면서 다른 네임스페이스에 존재하는 ConfigMap이나 Secret을 읽어들여 정보를 탈취한다. 두 번째는 “권한 상승 트리거”로, 오퍼레이터가 특정 이벤트(예: CR 업데이트)를 감지하면 클러스터‑스코프 RoleBinding을 자동 생성하거나 기존 Role을 수정해 공격자가 클러스터‑레벨 권한을 획득하도록 만든다. 두 전략 모두 오퍼레이터가 가진 높은 RBAC 권한을 전제로 하며, 공격자는 사전에 컨테이너를 탈취할 필요가 없으므로 기존 공격 모델보다 실현 가능성이 높다.

정적 분석 도구는 Go 언어 기반 오퍼레이터 코드를 AST 수준에서 파싱해, (1) CRD 선언 시 스코프가 Namespace 로 지정된 경우, (2) 컨트롤러 로직에서 클러스터‑스코프 API를 호출하는 경로를 탐지한다. 데이터 흐름 분석을 통해 입력 파라미터(사용자 제공 CR)와 API 호출 간의 연관성을 추적함으로써 “스코프 미스매치” 가능성을 높은 정확도로 식별한다. 2 268개의 오퍼레이터 샘플을 대상으로 수행한 결과, 321개(≈14 %)가 최소 하나 이상의 위험한 호출을 포함하고 있었으며, 이 중 8개는 실제 CVE로 이어졌다.

완화 방안으로는 (1) CRD 설계 단계에서 스코프를 명시적으로 검증하고, (2) 오퍼레이터 코드에서 클러스터‑스코프 API 사용을 최소화하거나, 사용 시 반드시 검증된 입력만 허용하도록 입력 검증 로직을 강화한다. 또한, 자동화된 패치 생성기와 오퍼레이터 개발 가이드라인을 공개해 개발자 커뮤니티가 사전에 취약을 차단하도록 지원한다.