사례5건

5건 중 1~5번째

1. 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나 다른 인그레스 컨트롤러로 옮겨야 한다.

   사례 보기
2. IL-0065 Argo CD의 Redis 캐시가 기본으로 암호 없이 클러스터 안 모든 파드에 열려 있어, 캐시된 매니페스트를 바꿔치기해 클러스터를 장악할 수 있었다

   Cycode2024

   증상

   운영 중 장애로 드러난 증상은 없다. 이 사례는 Cycode Labs가 Argo CD를 조사하다 찾은 취약점 CVE-2024-31989이고, 심각도 점수는 9.1이다.

   무단 접근과 낯선 워크로드

   촉발

   클러스터 안의 권한 낮은 파드 하나가 kube-DNS로 Argo CD Redis 주소를 찾아 6379 포트로 암호 없이 접속할 수 있었다. Argo CD는 캐시에 든 매니페스트를 cacheEntryHash로 검증했는데, 이 해시는 비밀 키 없이 fnv64a로 만든 값이라 누구나 다시 계산할 수 있었다.

   원인

   소프트웨어 결함

   구성 요소

   Argo CD

   기여 요인

   기본 설정 방치과도한 영향 범위설정 내 자격 증명

   감지

   Cycode Labs가 Argo CD의 쿠버네티스 구성 요소를 조사하다 찾았다. 2024년 1월 18일 GitHub Security Advisories로 Argo CD 팀에 알렸다.

   조치

   • Argo CD 팀이 2024년 5월 21일 Redis 서버 암호를 미리 정해 두는 2.11.1, 2.10.10, 2.9.15, 2.8.19 버전을 냈다. 사전 정보 없이는 Redis에 접속할 수 없게 됐지만, 문제를 일부만 막는 조치였다.

   교훈

   Argo CD를 2.11.1, 2.10.10, 2.9.15, 2.8.19 이상으로 올린다. argocd-redis-network-policy 네트워크 정책이 있고 켜져 있는지 확인한다. 네트워크 정책이 실제로 적용되려면 CNI가 제대로 설정돼 동작해야 한다. Argo CD 플러그인으로 Secret을 넣지 말고 컨트롤러 방식의 Secret 관리 도구를 써서 Secret이 Redis에 남지 않게 한다. 보안을 더 챙기려면 Argo CD를 다른 애플리케이션과 분리된 전용 클러스터에 둔다. 비밀 키 없이 만든 해시는 아무나 다시 계산할 수 있어서 무결성을 지켜 주지 못한다.

   사례 보기
3. IL-0132 잘못된 리소스 정리 작업이 Vertex AI 예측 엔드포인트를 전역에서 삭제된 것으로 표시해 고객 모델이 내려가고 예측 요청이 4시간 넘게 실패했다.

   Google Cloud2022

   증상

   2022-06-02 10:10 US/Pacific 부터 Vertex AI Online Prediction 의 오류율이 올라갔다. 리전과 사용 패턴에 따라 요청의 30% 에서 100% 가 실패했다.

   오류율 상승리소스 삭제서비스 중단

   촉발

   잘못된 리소스 정리 작업이 Vertex 예측 엔드포인트를 전역에서 삭제된 것으로 표시했다.

   원인

   소프트웨어 결함

   구성 요소

   모델 요청 라우팅

   기여 요인

   자동화 증폭과도한 영향 범위

   감지

   Google 은 13:58 US/Pacific 에 상태 페이지에 첫 공지를 올렸고, 이 공지는 문제가 10:20 US/Pacific 에 시작됐다고 적었다. 나중에 나온 짧은 장애 보고서는 시작 시각을 10:10 으로 적었다.

   조치

   • 삭제된 것으로 표시된 Vertex 예측 엔드포인트를 복구했고, 서비스가 완전히 회복됐다.

   사례 보기
4. IL-0106 잘못된 IngressRoute 매니페스트가 Traefik v2 버그를 건드려 Traefik 파드가 모두 재시작된 뒤 Kubernetes 의 모든 서비스가 404 를 냈다

   DFDS2021

   증상

   2021-09-06 08:00 UTC 에 Kubernetes 의 모든 서비스가 404 를 내기 시작했다. 30분 전인 07:30 에는 노드를 자동으로 교체하는 롤오버가 시작됐다.

   서비스 중단오류율 상승프로브 실패

   촉발

   2021-09-01 11:34 UTC 에 형식이 잘못된 IngressRoute 가 Kubernetes 에 적용됐다. 이 매니페스트는 2.5 미만 Traefik v2 의 버그를 건드렸지만, 버그는 Traefik v2 파드가 모두 재시작된 뒤에야 드러났다. 2021-09-06 07:30 에 자동 노드 롤오버가 시작됐고, 08:00 에 모든 서비스가 404 를 냈다.

   원인

   소프트웨어 결함

   구성 요소

   인그레스 컨트롤러클라우드 로드 밸런서

   기여 요인

   늦게 드러난 변경설정 테스트 부재과도한 영향 범위

   감지

   08:00 UTC 에 모든 서비스가 404 를 내기 시작했고 08:05 에 원인 조사를 시작했다. 감지까지 5분이 걸렸다.

   조치

   • ALB 헬스체크 경로를 바꿔 08:15 에 ALB 대상을 healthy 로 되돌렸지만 404 는 멈추지 않았다.
   • 08:50 에 주 인그레스 컨트롤러를 Traefik v1 으로 되돌리기로 하고, 09:00 에 손으로 롤백했다.
   • 09:10 에 잘못된 IngressRoute 를 손으로 지워 근본 원인과 Traefik v2 버그를 확인했다.
   • 09:20 에 바꾼 내용을 업스트림에도 반영했다.

   후속 조치

   • 버그가 고쳐진 Traefik v2.5 로 올리고 버그가 사라졌는지 확인한다.
   • Traefik v2 헬스체크 경로를 더 믿을 만한 경로로 바꾼다.
   • 인그레스 컨트롤러를 클러스터 바깥에서 확인하는 liveness 점검을 둔다.
   • 워크로드를 나눠 장애가 번지는 범위를 줄이는 방안을 검토한다.
   • Traefik v2 API 에서 짧은 시간에 많은 변경이 일어나는지 모니터링하는 방법을 알아본다.
   • 노드 롤오버 중과 롤오버 뒤에 스모크 테스트를 돌리는 방법을 알아본다.

   교훈

   Traefik v2 는 오류를 드러내지 않고 실패해서 조사를 ALB 쪽으로 잘못 이끌었다. 공식 API 스키마도 잘못된 매니페스트 적용을 막지 못했다. 팀은 대응 과정에서 장애 관리자를 정했다면 도움이 됐을 것으로 봤다. 그리고 워룸 회의를 녹화하고, 대응에 참여하지 않는 사람은 글로만 제안하고, 일지를 남기자고 정리했다. 대응 초반에 각자의 생각과 직감을 짧게 나누는 시간도 갖자고 했다.

   사례 보기
5. IL-0038 kubelet 설정 변경을 롤링 업데이트하다 쿠버네티스 버그로 kubelet 이 올라오지 못해 한 클러스터의 노드가 NotReady 가 되고 파드 절반쯤이 축출됐다

   Oath2018

   증상

   kubelet 변경을 클러스터 전체에 롤링 업데이트하던 중 kubelet 이 다시 올라오지 못했다. 쿠버네티스 API 는 노드가 죽었다고 판단했고 노드들이 NotReady 상태로 바뀌었다.

   노드 NotReady파드 축출파드 Pending

   촉발

   kubelet 변경을 롤링 업데이트로 배포했다. kubelet 은 재시작할 때 시작 전에 임시 cgroup 파일을 정리하는데, 이 과정에서 쿠버네티스 버그로 멈췄다. 이 업데이트가 한 클러스터의 노드 전체로 퍼졌다.

   원인

   소프트웨어 결함

   구성 요소

   kubelet쿠버네티스 컨트롤러 매니저

   기여 요인

   헬스 프로브 부재과도한 영향 범위

   감지

   업데이트 중 kubelet 이 올라오지 않으면서 노드가 NotReady 로 바뀌었고, 그래프에서 eviction 큐에 들어가 축출되는 노드 수가 늘어나는 것이 보였다.

   조치

   • 해당 데이터 센터에서 다음 데이터 센터로 페일오버해 사용자를 옮겼다.

   후속 조치

   • kubelet 업데이트를 적용한 뒤 테스트 프레임워크로 kubelet 을 검증하고, 검증이 끝나야 다음 30% 묶음의 업데이트로 넘어가게 했다.

   교훈

   kubelet 을 업그레이드한 뒤에는 반드시 테스트한다. kubelet API 에 간단한 curl 명령 하나만 보내 봐도 충분하다. 노드 컨트롤러는 노드의 50% 이상이 NotReady 가 되면 축출 속도를 늦추고, 노드가 모두 내려가면 full disruption 모드로 들어가 축출을 멈춘다. 이 동작 덕분에 이번 장애에서 파드의 절반이 살아남았다. 데이터 센터와 클러스터가 여럿이면 품질이 떨어진 데이터 센터에서 다른 데이터 센터로 페일오버해 사용자를 빠르게 옮길 수 있다.

   사례 보기

원인별1