사례32건

32건 중 2~6번째

1. IL-0069 공격자가 탈취한 서비스 어카운트 토큰으로 운영 쿠버네티스 클러스터에서 클라우드 백엔드와 금융 인프라까지 옮겨 가 암호화폐 거래소의 자금을 훔쳤다.

   Unnamed cryptocurrency exchange2026

   증상

   운영 쿠버네티스 클러스터에 공격자가 배포한 악성 파드가 올라왔다. 이 파드는 마운트된 서비스 어카운트 토큰을 밖으로 빼내도록 만들어져 있었다.

   무단 접근과 낯선 워크로드

   촉발

   공격자는 스피어피싱으로 거래소 개발자의 워크스테이션에 발판을 마련했다. 그 개발자의 권한 높은 클라우드 세션이 열려 있는 것을 이용해 운영 쿠버네티스 클러스터에 악성 파드를 배포했다.

   원인

   자격 증명 유출

   구성 요소

   RBAC 와 서비스 어카운트쿠버네티스 API 서버

   기여 요인

   과도한 영향 범위

   교훈

   RBAC 가 잘못됐거나 너무 넓으면 쿠버네티스 신원 하나가 클라우드 전체로 옮겨 가는 발판이 된다. Unit 42 는 RBAC 역할을 좁게 잡고 Restricted Pod Security 프로필을 쓰라고 권한다. 서비스 어카운트 토큰은 파드 수명에 묶이고 유효 기간이 짧은 projected 토큰으로 바꿔서, 빼앗기더라도 금방 쓸 수 없게 해야 한다. 쿠버네티스 감사 로그와 런타임 모니터링으로 ClusterRoleBinding 수정 시도, 낯선 IP 에서 쓰인 서비스 어카운트 토큰, 민감한 네임스페이스에 나타난 파드를 지켜봐야 한다.

   사례 보기
2. IL-0187 Spring Cloud Config Server 가 잠깐 내려가자 이를 헬스 체크에 포함한 모든 앱의 Liveness Probe 가 실패해 쿠버네티스가 파드를 계속 죽이고 다시 띄우면서 한 계열사 서비스가 마비됐다.

   Yonghyun Kim2025

   증상

   Config Server 업그레이드로 서버가 잠깐 응답하지 않는 동안, 클라이언트 앱 전부가 Liveness Probe 요청에 Config Server 와 연결되지 않는다며 실패로 응답했다.

   프로브 실패컨테이너 재시작 반복서비스 중단

   촉발

   Config Server 를 다운타임이 있는 방식으로 업그레이드하면서 서버가 잠깐 응답하지 않았다.

   원인

   의존성 장애

   구성 요소

   라이브니스·레디니스 프로브

   기여 요인

   기본 설정 방치자동화 증폭과도한 영향 범위

   교훈

   Liveness Probe 가 앱 자신이 아니라 외부 의존성의 상태까지 판단하면, 잠깐의 외부 장애나 네트워크 문제에도 쿠버네티스가 멀쩡한 앱을 죽인다. 일시적인 부하나 외부 서버 다운은 앱을 죽일 이유가 아니며, Readiness Probe 로 잠시 트래픽만 막으면 된다. 글쓴이는 특별한 이유가 없으면 Liveness Probe 를 끄라고 권한다. 꼭 써야 한다면 헬스 체크 경로에서 DataSourceHealthIndicator, ConfigServerHealthIndicator 같은 외부 Health Indicator 를 빼거나 /healthz 같은 별도 경로를 만들어야 한다. initialDelaySeconds 는 앱이 뜨는 데 걸리는 최대 시간보다 길게, failureThreshold 와 periodSeconds 는 넉넉하게 잡는다. 예를 들어 failureThreshold: 10, periodSeconds: 6 이면 60초 동안 연속으로 실패해야 재시작된다. 글쓴이가 운영한 레브잇 환경은 Liveness Probe 없이 2년 동안 안정적으로 서비스했다.

   사례 보기
3. IL-0122 여러 핵심 서비스가 함께 읽는 설정에 잘못된 값이 들어가 ChatGPT 파드가 크래시 루프에 빠졌다

   OpenAI2025

   증상

   2025-07-15 오후 7:43 PDT 부터 일부 사용자의 ChatGPT 대화에서 오류율이 올라갔다. 상태 페이지는 이 장애를 성능 저하로 표시했다.

   컨테이너 재시작 반복오류율 상승

   촉발

   내부 엔지니어가 잘못된 값이 든 설정 변경을 적용했다.

   원인

   설정 변경

   구성 요소

   –

   기여 요인

   과도한 영향 범위단계적 배포 부재

   조치

   • 잘못된 설정 값을 올바른 값으로 되돌렸다.
   • 영향받은 파드를 롤링 재시작해 곧바로 다시 동기화되게 했다.

   후속 조치

   • 중요한 설정 변경에 더 강한 안전장치를 둔다. 앞으로 이 서비스의 중요한 설정 변경은 클러스터 하나에 먼저 배포하고, 가용성이 떨어지면 자동 헬스 가드가 다음 배포를 멈춘다.
   • 여러 서비스가 함께 쓰는 설정을 서비스별 설정 값으로 나눠 서비스 사이의 의존 위험을 줄인다.
   • 배포 안전장치를 강화한다.

   사례 보기
4. IL-0121 우선순위 낮은 워크로드를 관리하는 컨트롤 플레인 클러스터에 잘못된 코드가 배포되어, 그 클러스터가 함께 관리하던 운영 추론 워크로드가 망가졌다

   OpenAI2025

   증상

   2025-07-09 오후 2:10 PDT 부터 gpt-4.1-mini 모델의 API 성공률이 떨어지고 ChatGPT 검색의 오류율이 크게 올랐다.

   오류율 상승

   촉발

   잘못된 코드 변경이 주로 우선순위 낮은 워크로드를 관리하는 컨트롤 플레인 클러스터에 배포되었다.

   원인

   배포 결함

   구성 요소

   –

   기여 요인

   과도한 영향 범위파괴적 변경 보호 장치 부재

   조치

   • 잘못된 코드 변경을 롤백했다.

   후속 조치

   • 운영 추론 워크로드가 이 컨트롤 플레인 클러스터에서 관리되지 않도록 막는 안전장치를 더했다.
   • 영향이 큰 컨트롤 플레인 변경을 배포할 때 쓰는 테스트를 강화했다.
   • 기존 운영 추론 워크로드를 모두 운영용 컨트롤 플레인 클러스터가 관리하도록 옮긴다.
   • 의도하지 않은 대규모 변경이 서비스에 일어나지 않게 막는 서킷 브레이커를 만든다.

   사례 보기
5. IL-0053 Ingress NGINX Controller의 어드미션 웹훅이 인증 없이 열려 있어, 조작한 Ingress 객체로 NGINX 설정을 주입해 원격 코드를 실행하고 클러스터의 모든 Secret을 읽을 수 있었다

   Wiz2025

   증상

   운영 중 장애로 드러난 증상은 없다. 이 사례는 Wiz Research가 Ingress NGINX Controller의 어드미션 컨트롤러 코드를 검토하다 찾은 취약점들이고, 이 취약점들을 묶어 IngressNightmare라고 부른다. CVSS v3.1 기본 점수는 9.8이다.

   무단 접근과 낯선 워크로드

   촉발

   인증 없는 어드미션 웹훅에 악성 Ingress 객체를 담은 AdmissionReview 요청을 보내면 공격이 시작된다. 어드미션 컨트롤러는 받은 Ingress 객체로 임시 NGINX 설정 파일을 만들고 nginx -t로 검사한다. 이때 어노테이션 값과 객체 UID가 제대로 걸러지지 않은 채 설정 파일에 들어갔다.

   원인

   소프트웨어 결함

   구성 요소

   인그레스 컨트롤러어드미션 웹훅

   기여 요인

   기본 설정 방치과도한 영향 범위

   감지

   Wiz Research가 어드미션 컨트롤러 코드를 검토하다 찾았다. 2024년 12월 31일 CVE-2025-1974와 CVE-2025-24514를 쿠버네티스에 보고했고, 2025년 1월 2일 CVE-2025-1097을, 1월 21일 CVE-2025-1098을 보고했다. 일반 공개는 2025년 3월 24일이었다.

   조치

   • 쿠버네티스가 2025년 2월 7일 CVE-2025-1098, CVE-2025-1097, CVE-2025-24514 주입 취약점을 고친 내부 패치를 만들었다.
   • 쿠버네티스가 어드미션 컨트롤러에서 NGINX 설정 검사를 빼 CVE-2025-1974를 막았고, 2025년 2월 20일 이를 Wiz에 알렸다.
   • 수정이 들어간 Ingress NGINX Controller 1.12.1과 1.11.5가 나왔다.

   교훈

   Ingress NGINX Controller를 최신 버전으로 올리고, 어드미션 웹훅 엔드포인트를 외부에 노출하지 않는다. 바로 올릴 수 없다면 네트워크 정책으로 쿠버네티스 API 서버만 어드미션 컨트롤러에 닿게 하거나 어드미션 컨트롤러를 잠시 끈다. Helm으로 설치했다면 controller.admissionWebhooks.enabled=false 로 다시 설치하고, 직접 설치했다면 ingress-nginx-admission ValidatingWebhookConfiguration을 지우고 컨트롤러의 --validating-webhook 인자를 뺀다. 업그레이드한 뒤에는 어드미션 컨트롤러를 다시 켠다. 어드미션 컨트롤러는 흔히 놓치는 공격 지점이다. 인증 없이 도는 웹 서버이면서 권한이 높고, 클러스터 안 어느 파드에서나 닿는다. 공격자가 컨테이너 탈출이나 SSRF로 파드 네트워크에 들어오는 일은 생각보다 쉽다. Wiz는 최소 권한 설계가 없어 공격이 클러스터 장악까지 이어졌다고 지적했다. 걸러지지 않은 사용자 입력을 nginx -t로 검사하는 것 자체도 위험하다고 봤다. 2025년 11월 갱신된 글에 따르면 ingress-nginx는 2026년 3월에 유지보수를 끝내고 지원을 종료한다. 그러니 Gateway API나 다른 인그레스 컨트롤러로 옮겨야 한다.

   사례 보기

원인별8