사례11건

11건 중 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-0103 EKS 노드 AMI 업데이트로 파드가 한꺼번에 다시 뜨자 인증서 요청이 몰린 외부 CA 가 과부하에 걸려 Istio 사이드카가 CrashLoopBackOff 에 빠졌다.

   Tetrate (unnamed U.S. federal customer)2025sev1

   증상

   미국 연방 기관 고객이 Istio 를 쓰는 EKS 클러스터 30여 개의 노드 AMI 를 업데이트하던 중, 그중 한 클러스터에서 사이드카가 주입된 워크로드가 시작하지 못하고 CrashLoopBackOff 에 빠졌다.

   컨테이너 재시작 반복프로브 실패

   촉발

   EKS 노드 AMI 업데이트로 수백 개의 새 파드가 동시에 떠서 외부 CA 로 인증서 요청이 한꺼번에 몰렸다.

   원인

   의존성 장애

   구성 요소

   Istio어드미션 웹훅노드 운영체제 이미지

   기여 요인

   기본 설정 방치한계 미인지

   감지

   노드 AMI 업데이트 중 한 클러스터에서 사이드카가 주입된 워크로드가 CrashLoopBackOff 로 시작하지 못했다. 처음 보인 신호는 istiod 초기화가 유난히 오래 걸리며 나온 Readiness probe 실패 이벤트였다.

   조치

   • istiod 레플리카를 40개에서 1개로 잠시 줄여 Istio 내부 처리를 늦추고 CA 부하를 덜었다.
   • Approved, Failed 상태로 멈춰 있던 CSR 들을 찾아 지웠다.
   • 파드를 한꺼번에 재시작하지 않고 단계적으로 재시작해 CA 요청이 다시 몰리지 않게 했다.

   교훈

   복잡한 인프라 장애를 진단할 때는 Istio 만이 아니라 서비스 메시를 둘러싼 구성 요소 전체를 봐야 한다. CSR 이벤트가 모두 성공으로 보여도 사이드카 로그에 CA 요청 실패가 있으면 외부 CA 의 처리 능력을 의심해야 한다. 노드 이미지 업데이트처럼 파드가 한꺼번에 다시 뜨는 작업을 하면 외부 CA 에 요청이 몰려, istiod 의 기본 CA 타임아웃 10초 안에 응답을 받지 못할 수 있다.

   사례 보기
3. IL-0180 GKE 컨트롤 플레인이 1.22 에서 1.23 으로 자동 업그레이드되면서 v1beta1 API 를 쓰던 Istio 1.7.4 가 제대로 동작하지 않았다

   Sunwoo Park2023

   증상

   2023-05-18 20:01 에 Slack 알림이 왔고, 운영 GKE 클러스터의 Istio 가 제대로 동작하지 않았다.

   서비스 중단

   촉발

   2023-05-18 19:52 에 GKE 컨트롤 플레인이 1.22.17-gke.7500 에서 1.23.17-gke.1700 으로 자동 업그레이드됐다. 클러스터의 Istio 1.7.4 는 networking.k8s.io/v1beta1 과 admissionregistration.k8s.io/v1beta1 API 를 쓰고 있었다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   IstioGKE 컨트롤 플레인어드미션 웹훅

   기여 요인

   미뤄 둔 업그레이드

   감지

   GKE 자동 업그레이드 9분 뒤인 20:01 에 Slack 알림이 왔다.

   조치

   • Istio 를 1.7.4 에서 1.13.3 으로 업그레이드해 GKE 1.23 과 호환되게 맞췄다.

   교훈

   Kubernetes, Istio 처럼 함께 쓰는 패키지는 버전 호환성 매트릭스를 GitHub 이나 문서에서 확인한다. 업그레이드는 운영 환경에 올리기 전에 테스트 환경에서 먼저 해 본다. ArgoCD 같은 자동화 도구로 배포와 버전을 관리한다. 운영 환경은 버전을 최소 6개월 유지하되 지원 종료 3개월 전에는 업그레이드한다. 업그레이드 전에는 항상 백업한다. 처음에는 Istio 지원 종료를 원인으로 봤지만, GKE 업그레이드 기록을 다시 보고 나서야 진짜 원인을 찾았다.

   사례 보기
4. IL-0060 쿠버네티스 1.24 업그레이드로 node-role.kubernetes.io/master 레이블이 사라지자 이 레이블에 기대던 Calico 라우트 리플렉터가 동작을 멈춰 레거시 클러스터의 네트워크가 모두 끊기고 Reddit 이 314분 동안 멈췄다

   Reddit2023

   증상

   2023년 3월 14일 19시 UTC 직후 엔지니어가 Old Reddit 이라 불리는 레거시 스택을 돌리는 클러스터의 업그레이드를 시작했다. 2분쯤은 괜찮아 보였지만 곧 사이트 전체가 갑자기 멈췄다. CDN 엣지의 상태 코드별 RPS 그래프가 이를 보여 주었다. 사용자는 오류 페이지나 글이 하나도 없는 홈페이지를 보았다.

   서비스 중단오류율 상승DNS 조회 실패모니터링 중단파드 ContainerCreating 정체컨트롤 플레인 지연

   촉발

   Reddit 에서 가장 중요한 클러스터 가운데 하나인 레거시 클러스터를 쿠버네티스 1.23 에서 1.24 로 업그레이드했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   Calico쿠버네티스 API 서버어드미션 웹훅etcd

   기여 요인

   코드로 관리되지 않는 설정스테이징 불일치미검증 백업모니터링 사각지대단일 장애점

   감지

   업그레이드를 시작하고 2분쯤 뒤 CDN 엣지의 상태 코드별 RPS 그래프에서 사이트가 멈춘 것이 보였다. 팀은 곧바로 장애를 선언했고 3분 안에 대응 인원이 통화에 모였다. 엣지 지표는 일부러 클러스터와 분리되어 있어 살아 있었지만, 클러스터 자체의 지표는 모두 사라졌다.

   조치

   • API 서버에서 타임아웃을 내던 Open Policy Agent 의 웹훅 설정을 지웠다.
   • 복원 뒤 어차피 쓸 수 없게 될 워커 노드를 모두 종료했다.
   • 컨트롤 플레인 노드 두 대를 종료하고, 남은 한 대의 구성 요소를 다운그레이드한 뒤 그 노드에 백업 데이터를 복원했다.
   • 단일 노드 컨트롤 플레인이 부하에 무너지지 않도록 클러스터 오토스케일러를 껐다.
   • 새 컨트롤 플레인 노드를 띄우고, 호스트명이 맞지 않던 TLS 인증서를 새로 만들어 노드들을 합류시켰다.
   • 트래픽을 1% 에서 시작해 5%, 10%, 20%, 35%, 55%, 80%, 100% 로 조금씩 늘렸다.
   • 트래픽이 돌아올 때 문제를 일으키지 않도록 손으로 멈춰 두었던 민감한 레거시 서비스를 조심스럽게 다시 켰다.

   후속 조치

   • 클러스터 구성을 코드로 관리해 모든 선택에 기록이 남게 하고, 코드로 만들 수 없는 것은 자세히 문서로 남긴다.
   • 클러스터마다 다른 맞춤형 구성을 걷어 내고 모든 클러스터의 구성 요소를 표준화한다.
   • 모든 클러스터를 최대한 같은 모습으로 유지하고 필요하면 다시 만들거나 복제할 수 있도록 클러스터 전체의 수명 주기를 관리하는 도구를 만든다.
   • 믿고 테스트에 쓸 수 있는 프리프로덕션 클러스터를 더 둔다.
   • 백업 복원 절차를 개선하고 클러스터 업그레이드를 안전하게 만든다.

   교훈

   쿠버네티스 버전과 구성 요소 업그레이드는 여전히 위험하다. 미리 테스트하고 검증해도 이번처럼 처음 보는 방식으로 깨질 수 있다. 쿠버네티스에는 공식 다운그레이드 절차가 없어, 롤백하는 방법은 백업에서 복원하는 것뿐이다. 복원 절차가 환경 변화를 따라가지 못하면 실제 장애 때 그 자리에서 고쳐 써야 하고, 복원을 결정하기까지 오래 망설이게 된다. 이번 복원은 결국 성공했지만 절차는 개선해야 한다. 코드로 남기지 않은 설정은 아는 사람이 떠나면 아무 기록도 남지 않는다. 라우트 리플렉터 설정이 어디에도 커밋되어 있지 않아 장애 중에 누구도 의심하지 못했다. 지표가 클러스터 안에서만 수집되면 클러스터가 망가질 때 함께 사라진다. 이번에는 로그 수집 에이전트가 영향을 받지 않아 원인을 추적할 수 있었다. 클러스터마다 다른 맞춤형 구성이 쌓이면 장애가 잦아진다. 직접 원인은 노드 레이블이었지만 근본 원인은 일관성 부족이었다.

   사례 보기
5. IL-0107 오래된 Kyverno 가 서드파티 인증서 체인 만료로 크래시 루프에 빠졌고, failurePolicy 가 fail 인 웹훅이 응답하지 않아 Service 리소스의 생성, 수정, 삭제가 88분 동안 막혔다.

   DFDS2022

   증상

   2022년 8월 3일 11:38 UTC 에 한 사용자 팀이 해당 쿠버네티스 클러스터에 Service 리소스를 적용하는 데 문제가 있다고 알려 왔다.

   배포 실패컨테이너 재시작 반복

   촉발

   서드파티 애플리케이션이 쓰는 인증서 체인이 만료되면서 Kyverno 가 크래시 루프에 빠졌다. DFDS 쪽에서는 아무것도 바꾸지 않았다.

   원인

   인증서·자격 증명 만료

   구성 요소

   정책 엔진어드미션 웹훅

   기여 요인

   미뤄 둔 업그레이드기본 설정 방치모니터링 사각지대초기 신호 무시

   감지

   11:38 UTC 에 한 사용자 팀이 클러스터에 Service 리소스를 적용하지 못한다고 알려 오면서 장애가 드러났다. 팀은 11:50 UTC 에 조사를 시작했고, 보고서는 탐지까지 걸린 시간을 12분으로 적었다.

   조치

   • 쿠버네티스 샌드박스에서 문제를 재현하고, Kyverno 를 더 새 Helm 차트 버전으로 올리는 수정을 샌드박스에 먼저 배포했다.
   • 13:06 UTC 에 같은 수정을 영향받은 운영 클러스터에 배포했다.

   후속 조치

   • Kyverno 를 모니터링 대상에 넣는다.
   • Kyverno 를 어떻게 구성했는지 내부 문서로 정리한다.
   • 애플리케이션의 인증서에서 정확히 무엇이 문제였는지 조사한다.
   • 앞으로 ClusterPolicy 리소스의 failurePolicy 를 바꿀지 검토한다.

   교훈

   운영 문제는 처음부터 'Ops Day to Day' 보드에 올려야 한다.

   사례 보기

원인별7