사례5건

5건 중 1~5번째

1. IL-0092 ingress-nginx 를 1.12.0 에서 1.14.3 으로 올리자 새 ModSecurity 와 OWASP Core Rule Set 이 정상 요청을 오탐으로 막아 HMPPS 사용자가 인증하지 못했다.

   UK Ministry of Justice2026

   증상

   2026년 3월 30일 08:56 에 Cloud Platform 팀은 #hmpps-auth-audit-registers 슬랙 채널에서 ModSecurity 가 요청을 예상치 못하게 막는다는 메시지를 봤다. 같은 날 07:11 에 운영 인그레스 세 개에 새 ingress-nginx 를 배포하기 시작한 뒤였다.

   오류율 상승서비스 중단

   촉발

   Cloud Platform 팀이 ingress-nginx 1.14.3 을 운영 인그레스 세 개에 배포했다. 이 버전에는 새 ModSecurity WAF 와 새 OWASP Core Rule Set 이 들어 있었다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러웹 애플리케이션 방화벽 규칙

   기여 요인

   스테이징 불일치

   감지

   Cloud Platform 팀은 HMPPS Auth 팀 슬랙 채널의 메시지로 장애를 알았다. 팀은 08:56 에 #hmpps-auth-audit-registers 채널에서 ModSecurity 가 요청을 예상치 못하게 막는다는 메시지를 봤고, 09:14 에 장애를 선언했다.

   조치

   • 09:14 에 ingress-nginx 롤백을 시작해 09:43 에 마쳤다.
   • HMPPS 개발자들이 HMPPS Auth 로 가는 트래픽을 막는 규칙을 자기 ModSecurity 설정에서 예외 처리했다.
   • Cloud Platform 팀이 posthog 쿠키가 걸리는 규칙을 플랫폼의 모든 서비스에서 임시로 예외 처리했다.
   • 두 예외를 둔 상태로 새 ingress-nginx 를 다시 배포해 14:00 에 마쳤다.

   후속 조치

   • posthog 쿠키의 범위를 줄여 모든 *.justice.gov.uk 서비스로 가는 요청에 실리지 않게 했다. 다만 이 변경과 CRS 규칙 배포 사이가 짧아 사용자 브라우저의 쿠키가 만료되거나 바뀔 시간이 모자랐다.
   • posthog 쿠키가 충분히 많은 사용자 브라우저에서 만료되면 플랫폼 전체에 넣은 임시 예외를 없앤다.
   • 서비스 팀들에게 개발과 테스트 워크로드에 비운영 인그레스 컨트롤러를 쓰라고 다시 강조해, 이후 ModSecurity 와 CRS 업데이트에서 생길 문제를 미리 찾게 한다.
   • Cloud Platform 3.0 에서는 운영과 비운영 워크로드를 다른 클러스터로 나눠 비운영 워크로드가 반드시 비운영 인그레스를 거치게 한다.

   교훈

   WAF 규칙 세트 업데이트는 보안을 높이려는 변경이어도 정상 트래픽을 막을 수 있다. 베타 인그레스와 비운영 배포로 시험 기회를 줬어도 서비스 팀들이 개발과 테스트에 비운영 인그레스를 실제로 쓰지 않으면 Expect 헤더 같은 오탐은 운영에서야 드러난다. 시험에서 찾은 문제라도 쿠키처럼 사용자 브라우저에 남는 값이면 대응이 효과를 내기까지 시간이 걸린다. 팀은 롤백으로 먼저 영향을 끊고 예외를 준비한 뒤 다시 배포해 같은 날 업그레이드를 마쳤다.

   사례 보기
2. IL-0090 ModSec 인그레스 컨트롤러 모듈을 v3.33.0 으로 올린 뒤 검증 웹훅 호출이 x509 인증서 오류로 실패해, 모든 인그레스 생성과 변경이 막히고 사용자 애플리케이션 배포가 멈췄다.

   UK Ministry of Justice2021

   증상

   2021년 6월 9일 13:15 에 한 사용자가 #ask-cloud-platform 채널에 UAT 애플리케이션을 배포하다가 오류가 났다고 알렸다.

   배포 실패

   촉발

   ModSec 인그레스 컨트롤러 모듈을 v3.33.0 으로 업그레이드했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

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

   기여 요인

   스테이징 불일치

   감지

   13:15 에 한 사용자가 #ask-cloud-platform 채널에 UAT 애플리케이션 배포 오류를 올리면서 장애가 드러났다. 장애 선언은 13:54 였다.

   조치

   • ModSec 인그레스 컨트롤러 모듈을 v0.0.7 로 롤백했다.

   후속 조치

   • 이 문제가 테스트 클러스터에서 왜 걸러지지 않았는지 알아본다. 문제를 재현해 보고 테스트를 하나 더 둘지 판단한다. 티켓 #2972.
   • 스모크 테스트에 Alertmanager 의 알림을 확인하는 테스트를 더한다. 티켓 #2973.
   • ModSec 컨트롤러를 쓰는 helloworld 앱을 두고, 스모크 테스트로 트래픽이 실제로 흐르는지 확인한다. 티켓 #2974.
   • 새 버전의 ModSec 모듈이 EKS 의 live-1 과 live 에서 동작하게 만든다. 지금은 옛 버전과 새 버전 모두 live 에서 동작하지 않는다. 티켓 #2975.

   사례 보기
3. IL-0089 테스트 클러스터 삭제 스크립트가 운영 클러스터 live-1 을 대상으로 실행돼 인그레스 컨트롤러, 모니터링, 인증서 구성 요소가 지워지고 사용자 서비스에 접속할 수 없게 됐다.

   UK Ministry of Justice2020

   증상

   팀은 2020년 9월 21일 18:27 에 처음 장애를 알아챘다. Cloud Platform 에서 돌아가는 서비스 일부에 사용자가 접속하지 못했다.

   서비스 중단리소스 삭제모니터링 중단오래된 엔드포인트 라우팅

   촉발

   테스트 클러스터를 지우려고 삭제 스크립트를 실행했는데, kube 컨텍스트가 잘못 잡혀 있어 스크립트가 운영 클러스터 live-1 을 대상으로 돌았다.

   원인

   운영 실수

   구성 요소

   인그레스 컨트롤러파드용 자격 증명 중개자external-dns클라우드 로드 밸런서Prometheus

   기여 요인

   파괴적 변경 보호 장치 부재

   감지

   팀은 18:27 에 처음 장애를 알아챘고, 13분 뒤인 18:40 에 장애를 선언했다.

   조치

   • 기본 인그레스 컨트롤러를 먼저 되살리고, 인그레스 컨트롤러가 의존하는 external-dns 와 kiam 도 함께 되살렸다.
   • Route53 TXT 레코드의 잘못된 owner 값을 고쳐 external-dns 가 Formbuilder 레코드를 새 NLB 로 바꾸게 했다.
   • 남은 구성 요소는 대상을 지정한 apply 로 되살렸다.
   • apply 파이프라인을 돌려 환경 저장소에 있는 인증서, ServiceMonitor, Prometheus 규칙을 모두 다시 만들었다.

   사례 보기
4. IL-0088 팀별 ingress 컨트롤러 모듈 0.1.0 이 만든 검증 웹훅이 live-1 클러스터에서 새 Ingress 생성을 모두 x509 오류로 막았다

   UK Ministry of Justice2020

   증상

   2020-09-07 12:39 에 Cloud Platform 의 live-1 클러스터에서 새 Ingress 규칙이 만들어지지 않는 문제가 처음 감지되었다. Ingress API 가 POST 요청을 100% 거부하고 있었다.

   배포 실패

   촉발

   팀별 ingress 컨트롤러 모듈 0.1.0 은 ValidatingWebhookConfiguration 리소스를 만들도록 바뀌었다. live-1 클러스터에서는 새 0.1.0 컨트롤러 하나가 AWS 리소스 한도에 걸려 만들어지지 않았다.

   원인

   배포 결함

   구성 요소

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

   기여 요인

   단일 장애점

   감지

   문제는 2020-09-07 12:39 에 처음 감지되었다. 확인해 보니 Ingress API 가 POST 요청을 100% 거부하고 있었다. 팀은 Slack 스레드에서 조사를 시작했고 12:54 에 장애를 선언했다.

   조치

   • 0.1.0 이 만든 추가 admission 컨트롤러를 손으로 모두 지웠다.
   • 모듈에서 admission 웹훅을 빼고 새 릴리스 0.1.1 을 냈다.
   • 0.1.0 을 쓰던 ingress 모듈을 모두 0.1.1 로 올렸다.

   교훈

   검증 웹훅을 켜는 옵션 하나가 네임스페이스에 있는 ingress 컨트롤러 파드 전체의 단일 장애점이 되었다. 컨트롤러 하나가 뜨지 못하자 그 웹훅이 클러스터 전체의 새 Ingress 생성을 막았다.

   사례 보기
5. IL-0093 리더 ingress 컨트롤러 파드가 공유 메모리를 다 써서 ingress 컨트롤러 파드 6개 중 4개가 크래시 루프에 빠졌다

   UK Ministry of Justice2020

   증상

   2020-08-14 10:43 에 클러스터의 ingress 컨트롤러 파드 복제본 6개 중 2개가 크래시 루프에 빠진 것이 감지되었다.

   컨테이너 재시작 반복

   원인

   용량 한계

   구성 요소

   인그레스 컨트롤러

   기여 요인

   수동 조치 악화단일 장애점

   감지

   2020-08-14 10:43 에 ingress 컨트롤러 파드 6개 중 2개가 크래시 루프에 빠진 것이 감지되었다.

   조치

   • 리더 ingress 컨트롤러 파드를 재시작했다. 그러자 다른 파드들이 리더에 연결해 최신 nginx.config 파일을 받았다.

   사례 보기

원인별4