🇰🇷 한글 설명
Aiven Operator 0.31.0~0.37.0 버전에서 개발자는 자신의 네임스페이스에서 ClickhouseUser CRD 생성 권한만으로 Operator의 클러스터 레벨 ServiceAccount를 악용하여 다른 네임스페이스의 모든 시크릿(DB 자격증명, API 키, 서비스 토큰)을 탈취할 수 있습니다. Operator가 입력받은 네임스페이스 값을 검증하지 않는 Confused Deputy 문제로 인한 권한 상승 취약점입니다.
💡 쉬운 설명
쿠버네티스의 Aiven Operator에 권한 검증 부재 버그가 있어서, 일반 개발자도 자신의 공간에서 특정 명령어를 실행하면 다른 관리자 공간의 비밀번호나 API키를 빼낼 수 있습니다. 마치 은행원(Operator)이 신분증을 확인하지 않고 누가 물어본 다른 고객의 통장을 열어주는 것과 같습니다.
🇺🇸 원문 (English)
Aiven Operator allows you to provision and manage Aiven Services from your Kubernetes cluster. From 0.31.0 to before 0.37.0, a developer with create permission on ClickhouseUser CRDs in their own namespace can exfiltrate secrets from any other namespace — production database credentials, API keys, service tokens — with a single kubectl apply. The operator reads the victim's secret using its ClusterRole and writes the password into a new secret in the attacker's namespace. The operator acts as a confused deputy: its ServiceAccount has cluster-wide secret read/write (aiven-operator-role ClusterRole), and it trusts user-supplied namespace values in spec.connInfoSecretSource.namespace without validation. No admission webhook enforces this boundary — the ServiceUser webhook returns nil, and no ClickhouseUser webhook exists. This vulnerability is fixed in 0.37.0.
📍 영향받는 시스템
Aiven Operator 0.31.0 ~ 0.36.x (0.37.0 이상에서 패치됨)
⚔️ 공격 벡터
attacker가 ClickhouseUser CRD를 자신의 네임스페이스에서 생성하되, spec.connInfoSecretSource.namespace에 피해자 네임스페이스 지정 후 kubectl apply로 실행
🛡️ 대응 방법
Aiven Operator를 0.37.0 이상으로 즉시 업그레이드하고, 네임스페이스 간 ServiceAccount 권한 최소화 및 Admission Webhook 정책 적용
🔧 검증 코드
출력된 버전 번호가 0.37.0 이상이면 안전, 0.36.x 이하면 취약함
kubectl get deployment aiven-operator -n aiven-operator -o jsonpath='{.spec.template.spec.containers[0].image}' 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+'