사례6건

6건 중 6~6번째

1. IL-0052 인증 없이 인터넷에 열린 Weave Scope 대시보드를 통해 암호화폐 채굴기가 개발 클러스터와 스테이징 클러스터의 모든 노드에서 돌았다.

   JW Player2019

   증상

   Datadog 이 스테이징 환경의 정규화한 load average 가 높다고 경보를 보냈다. 팀은 원인을 정상 서비스 하나의 부하 증가로 판단했고, 정상 동작으로 여겼다.

   노드 CPU 고부하무단 접근과 낯선 워크로드

   촉발

   Weave Scope 를 배포할 때 쿠버네티스가 로드 밸런서에 0.0.0.0/0 에서 80 포트로 들어오는 접근을 허용하는 보안 그룹을 연결했다. 팀은 AWS 콘솔에서 이 보안 그룹을 손으로 고쳐 허용 목록 밖의 트래픽을 막았지만, 쿠버네티스가 얼마 뒤 이 수정을 되돌렸다. 그 결과 Weave Scope 대시보드가 인증 없이 인터넷에 열렸고, 자동화된 크롤러가 이를 찾아냈다.

   원인

   설정 변경

   구성 요소

   클러스터 대시보드클라우드 로드 밸런서

   기여 요인

   초기 신호 무시기본 설정 방치과도한 영향 범위모니터링 사각지대

   감지

   Datadog 이 정규화한 load average 경보를 0일 차 21:06 EST 에 스테이징에서, 1일 차 16:53 EST 에 개발 환경에서 보냈다. 팀은 정상 서비스의 부하로 보고 경보를 뮤트했다. 3일 차 17:40 EST 에 부하 증가가 나흘째 이어지자 엔지니어가 노드에 SSH 로 들어가 top 으로 CPU 를 100% 쓰는 gcc 프로세스를 찾았다.

   조치

   • Weave Scope 를 멈추고 모든 쿠버네티스 클러스터에서 그 배포를 지웠다.
   • 인스턴스에 무단 접근한 흔적이 있는지 접근 로그를 확인했다.
   • gcc 프로세스의 외부 연결을 조사해 마이닝 풀과만 통신한다는 것을 확인했다.
   • 영향을 받은 노드 하나를 나중에 조사하려고 클러스터에서 격리했다.
   • 모든 클러스터의 노드를 전부 새로 만들어 교체하고 감염을 모두 없앴다.

   후속 조치

   • 모든 쿠버네티스 설정 파일과 사내 배포 YAML, 보안 그룹을 감사해 의도치 않게 외부에 열린 서비스나 잘못된 설정이 없는지 확인했다.
   • load 대신 더 의미 있는 모니터를 정하고, 작업량이 늘 때 경보가 쏟아지지 않고 실제 이상을 가려내도록 다듬는다.
   • falcon 이나 sysdig 같은 도구로 행위 모니터링과 이상 탐지, 침입 탐지를 할 수 있는지 검토한다.
   • Istio 나 Linkerd 로 종단 간 네트워크 트래픽을 파악하고 통제해 무단 접근을 막는 방안을 검토한다.
   • Docker 이미지와 컨테이너에서 알려진 취약점을 검사하는 데 드는 계산 비용을 따져 본다.
   • 아키텍처 논의 시간 일부를 떼어 컨테이너를 root 로 돌리는 것처럼 예전에 내린 결정을 다시 검토하기로 했다.
   • 일부 팀원에게만 있던 정보를 팀 전체와 나눠, 대규모 쿠버네티스 버전 업그레이드 같은 큰 프로젝트를 모든 엔지니어가 볼 수 있게 한다.

   교훈

   load 기반 모니터링은 클러스터의 이상을 가려내는 좋은 지표가 아니었다. 정상 서비스가 낸 경보 소음이 침입 신호를 가렸다. 쿠버네티스가 관리하는 리소스를 손으로 고치면 쿠버네티스가 그 변경을 되돌린다. 로드 밸런서를 내부용으로 정의하거나 보안 그룹 규칙을 쿠버네티스 YAML 에 넣었어야 했다. 인증 없는 내부 대시보드, --privileged 와 root 로 도는 컨테이너, 호스트 파일 시스템 마운트가 겹치면 열린 로드 밸런서 하나로 모든 노드에서 코드가 실행될 수 있다. 컨테이너를 root 로 돌리는 것처럼 예전 인프라에서 물려받은 결정은 다시 검토해야 한다.

   사례 보기

원인별1