잠깐, 쿠버네티스가 무엇인가
본론에 들어가기 전에 용어부터 짚는다. 쿠버네티스(Kubernetes, 흔히 K8s로 줄여 쓴다)는 컨테이너를 자동으로 배포·확장·복구·운영해 주는 자동 운영 플랫폼이다. 쉽게 말해, 수십에서 수천 개의 컨테이너를 사람이 일일이 켜고 끄는 대신 "원하는 상태"만 선언하면 그 상태를 유지하도록 알아서 관리해 주는 시스템이다.
먼저 컨테이너는 애플리케이션과 그 실행 환경을 하나로 묶어 격리한 실행 단위다. 어디서든 동일하게 돌아가도록 포장한 상자라고 보면 된다. 쿠버네티스는 이 컨테이너들을 다음과 같은 구조로 다룬다.
| 용어 | 의미 |
|---|---|
| 파드(Pod) | 컨테이너를 실행하는 최소 배포 단위. 보통 컨테이너 한두 개를 담는다 |
| 노드(Node) | 파드가 실제로 돌아가는 물리·가상 서버 한 대 |
| 클러스터(Cluster) | 여러 노드를 묶은 전체 단위. 쿠버네티스가 관리하는 한 덩어리의 인프라 |
| 제어 영역(Control Plane) | 클러스터를 통제하는 두뇌. API 서버를 통해 모든 요청·변경이 처리된다 |
| 네임스페이스(Namespace) | 클러스터 안을 논리적으로 나눈 구획. 팀·서비스·환경별 격리에 쓴다 |
기업이 쿠버네티스를 쓰는 이유는 분명하다. 트래픽이 몰리면 파드를 자동으로 늘리고, 줄면 회수한다. 컨테이너가 죽으면 알아서 새로 띄운다. 배포도 무중단으로 굴러간다. 운영 효율은 비약적으로 오른다. 그런데 바로 이 "자동으로 늘었다 줄고, 죽으면 교체되는" 특성이 보안 로그 관점에서는 까다로운 숙제를 만든다. 다음 절의 이야기다.
컨테이너 환경이 로그 보안을 어렵게 만드는 이유
전통적인 서버는 한 번 띄우면 몇 달, 몇 년을 산다. 로그도 그 서버 디스크에 차곡차곡 쌓인다. 쿠버네티스는 다르다. 파드는 수요에 따라 자동으로 늘었다 줄고, 배포 한 번에 통째로 교체된다. 문제가 생긴 파드가 재시작되거나 삭제되면, 그 안의 로그도 함께 사라진다.
여기서 보안 관점의 핵심 원칙이 나온다. 컨테이너 로그는 컨테이너 밖으로 내보내(ship) 중앙에서 보존해야 한다. 노드에 남은 로그만 믿었다가는, 정작 침해를 조사할 시점에 그 파드도 그 노드도 이미 사라지고 없는 상황을 마주하게 된다. 휘발성이라는 컨테이너의 장점이 보안에서는 약점이 되는 셈이다.
게다가 들여다봐야 할 계층도 많다. 애플리케이션 컨테이너만이 아니라, 클러스터를 통제하는 제어 영역(control plane)과 노드까지 로그가 흩어져 있다. 이 분산된 로그를 한곳에 모아 같은 기준으로 검색·탐지·보존하는 것이 LogCenter가 하는 일이다.
무엇부터 수집할 것인가 — 쿠버네티스 로그의 우선순위
"컨테이너 로그를 다 모은다"는 접근은 비용도, 잡음도 감당하기 어렵다. 보안 관점에서 가치가 높은 순서로 추린다. 아래는 컨테이너 보안의 일반 원칙으로, 환경에 맞게 취사선택한다.
| 로그 종류 | 왜 중요한가 | 보안 가치 |
|---|---|---|
| API 서버 감사 로그 (audit log) | 누가 무슨 권한으로 클러스터에 무엇을 요청했는지 기록 | 최우선 — 권한 오남용·계정 탈취의 핵심 증적 |
| 컨테이너 stdout/stderr | 애플리케이션이 남기는 실제 동작·에러 | 높음 — 공격 시도·이상 동작의 1차 단서 |
| 노드·kubelet 로그 | 노드에서의 컨테이너 기동·실패·리소스 | 중간 — 노드 침해·비정상 워크로드 탐지 |
| 인그레스·네트워크 로그 | 외부에서 들어오는 요청과 내부 통신 | 높음 — 외부 위협 IP·비정상 트래픽 식별 |
특히 API 서버 감사 로그는 컨테이너 환경의 "방화벽 로그"에 해당한다. 권한 상승, 비정상적인 시크릿 접근, 예기치 않은 exec 실행 같은 행위가 모두 여기에 흔적을 남긴다. 다른 걸 못 모으더라도 이건 모아야 한다.
LogCenter는 어떻게 받아들이나 — 인덱스 유형과 클러스터 단위 관리
여기서부터는 제품 기능이다. 수집된 로그는 처리 레이어에 적재되는데, LogCenter는 인덱스 유형을 General과 Kubernetes로 구분한다. 즉 쿠버네티스 로그를 일반 로그와 다른 구조로 인식하고, K8s 고유의 인덱스 필드를 기준으로 다룰 수 있다.
이것이 실무에서 의미하는 바는 분명하다. 컨테이너 로그를 그냥 텍스트 덩어리로 쌓는 게 아니라, 쿠버네티스 메타데이터(네임스페이스·파드 등 인덱스 필드) 기준으로 검색·필터·탐지를 걸 수 있다는 뜻이다. 또한 원본 로그는 호스트뿐 아니라 클러스터 단위로 선택해 조회·다운로드·무결성 확인이 가능하다. 컨테이너가 사라져도 그 클러스터의 로그는 중앙에 남아 추적할 수 있다.
Save Data를 Indexed 또는 Parsing으로 두는 것이다. Raw로만 두면 검색·탐지·V보드에서 데이터가 채워지지 않는다.
잡음을 먼저 잡아라 — 로그 제외 필터
컨테이너 로그는 양이 폭발한다. 헬스체크, 정상 요청, 디버그 메시지가 초당 수천 줄씩 쏟아진다. 이걸 그대로 다 인덱싱하면 저장 비용과 검색 성능이 모두 망가지고, 정작 위협 신호가 잡음에 묻힌다. 그래서 수집 단계에서 불필요한 로그를 걸러내는 로그 제외 필터가 중요하다.
로그 제외 필터는 유형을 General과 Kubernetes로 구분해 만들 수 있다. 즉 쿠버네티스 인덱스 필드를 기준으로 "이 네임스페이스의 헬스체크 로그는 제외" 같은 조건을 직접 걸 수 있다. 필터는 OR·AND 조합과 다양한 오퍼레이터를 지원한다.
| 구성 요소 | 값 |
|---|---|
| 유형 | General / Kubernetes |
| 필터 유형 | OR / AND |
| 대상 | 인덱스 필드 + 오퍼레이터 + 값 |
| 오퍼레이터 | IS / IS NOT / LIKE / IS ONE OF / IS NOT ONE OF / IS BETWEEN / IS NOT BETWEEN / EXISTS |
사라지는 컨테이너, 남아야 하는 증적 — 보존과 무결성
컨테이너는 휘발성이지만 로그는 증거다. 침해 사고를 조사하거나 감사를 받을 때 필요한 것은 "그 시점의 원본 로그"이고, 그것이 위·변조되지 않았다는 보장이다. LogCenter는 이 두 가지를 모두 다룬다.
원본 로그는 주기적으로 백업·보관되며, 호스트/클러스터를 선택해 오브젝트명·저장일·파일 크기·무결성을 확인하고 다운로드할 수 있다. 백업 시 암호화 키를 설정해 원본의 위·변조를 방지하며, 무결성 검증에 실패한 항목은 파일 무결성 모니터링 화면에서 따로 모아 볼 수 있다.
보존 기간은 호스트별로 로그 파일과 인덱스 파일을 나눠 설정한다. 컨테이너 로그처럼 양이 많은 데이터는 인덱스 보존 기간을 짧게, 원본 보존 기간을 규제 요건에 맞춰 길게 가져가는 식의 분리 운영이 현실적이다.
탐지로 연결 — 컨테이너 로그도 결국 탐지가 목적이다
수집·보존은 준비 단계이고, 목적은 탐지다. LogCenter로 모은 쿠버네티스 로그에도 다른 로그와 동일하게 실시간·배치·시나리오 탐지를 걸 수 있고, CTI 교차 탐지와 종합 탐지 현황으로 이어진다. 컨테이너 환경에서 특히 유효한 탐지를 몇 가지 정리한다.
| 탐지 시나리오 | 활용 방법 |
|---|---|
| 파드 → 외부 위협 IP 통신 | 인그레스·네트워크 로그의 dst_ip를 CTI 위협 IP와 교차 탐지. 감염 컨테이너의 C2 통신 식별 |
| 비정상 exec·권한 상승 | API 서버 감사 로그에서 예기치 않은 exec·권한 변경을 키워드/시나리오 룰로 탐지(MITRE ATT&CK Containers 전술과 매핑) |
| 단계형 침해 | 비정상 인증 → 시크릿 접근 → 외부 전송으로 이어지는 흐름을 연쇄 시나리오 룰로 탐지 |
| 암호화폐 채굴 | 특정 노드/파드의 CPU 급증을 ML 이상(Anomaly)으로 조기 포착 |
구분해 두자면, 위의 탐지 가능성은 LogCenter의 탐지 기능(실시간·배치·시나리오·CTI·ML)을 컨테이너 로그에 적용한 것이고, "어떤 행위를 위협으로 볼 것인가"의 룰 설계는 환경에 맞춰 직접 구성하는 영역이다.
운영 체크리스트
- 로그를 밖으로 빼고 있는가. 파드·노드 로그가 LogCenter로 전달되고 있는지, 재시작·삭제 후에도 중앙에 남는지 확인한다.
- API 서버 감사 로그를 모으는가. 컨테이너 환경의 가장 중요한 증적이다. 우선순위 1번.
- Save Data가 Indexed/Parsing인가. Raw로만 두면 검색·탐지·V보드가 비어 있게 된다.
- 제외 필터가 과하지 않은가. 잡음만 걸러야지, 에러·이상 로그까지 버리면 안 된다. 변경 이력을 남긴다.
- 보존 기간이 규제를 만족하는가. 원본은 최소 6개월(ISMS-P), 인덱스는 비용에 맞춰 분리 설정.
- 무결성 검증이 켜져 있는가. 백업 암호화 키 설정과 무결성 모니터링을 정기 점검.
심층 사례 — 탈취된 토큰으로 시작된 컨테이너 암호화폐 채굴
컨테이너 침해는 흔히 자격 증명 탈취에서 시작해 리소스 남용으로 드러난다. 파드가 사라지기 전에 무엇을 남겨야 하는지를 보여주는 사례다.
| 단계 | 무슨 일이 있었나 | LogCenter에서 한 일 |
|---|---|---|
| ① 탈취 | 노출된 서비스계정 토큰이 외부에서 재사용됐다 | API 서버 감사 로그에 비정상 출처의 인증 요청이 기록됨 |
| ② 침투 | 탈취 토큰으로 파드에 접근해 컨테이너에서 exec 실행 | 감사 로그의 예기치 않은 exec를 키워드·시나리오 룰로 탐지 |
| ③ 채굴 | 암호화폐 채굴 프로세스가 기동돼 노드 CPU가 급증 | ML 이상(Anomaly)이 해당 노드의 비정상 CPU 패턴을 포착 |
| ④ 탐지 | 감사 로그 탐지와 ML 이상이 같은 파드를 동시에 지목 | 종합 탐지 현황에 표시, MITRE 전술과 매핑 |
| ⑤ 대응 | 해당 파드를 격리하고 토큰을 폐기 | 파드 삭제 전에 원본 로그·맥락을 티켓에 고정해 증적 확보 |
보안 담당자를 위한 활용 방안
컨테이너 환경의 보안 운영은 "사라지기 전에 남긴다"는 한 문장으로 요약된다. 휘발성 인프라에서 포렌식을 가능하게 만드는 실무 방안을 정리한다.
| 활용 방안 | 실무 적용 |
|---|---|
| API 감사 로그 최우선 | 컨테이너의 '방화벽 로그'에 해당한다. 권한 상승·시크릿 접근·비정상 exec의 핵심 증적이므로 다른 걸 못 모아도 이건 모은다 |
| 탐지 맥락 즉시 고정 | 파드가 사라지기 전에, 탐지 시점의 원본 로그·메타데이터를 티켓에 즉시 고정한다. 나중엔 그 파드도 노드도 없다 |
| 네임스페이스 위험 등급화 | prod 네임스페이스 로그를 우선 인덱싱·탐지하고, dev는 보존 위주로 차등 운영해 비용과 가시성을 맞춘다 |
| 제외 필터 변경관리 | 무엇을 거를지가 곧 가시성 정책이다. 필터 추가·수정은 승인·이력 관리 대상으로 다룬다 |
| east-west 통신 감시 | 외부 경계만 보면 파드 간 횡적 이동(lateral movement)을 놓친다. 내부 통신 로그도 수집 대상에 넣는다 |
| 암호화폐 채굴 조기 탐지 | 노드·파드 CPU 급증을 ML 이상(Anomaly)으로 포착한다. 리소스 지표를 보안 신호로 읽는다 |
컨테이너의 본질은 일시성이다. 떴다가 사라지는 것이 정상이다. 그래서 보안의 무게중심은 "컨테이너를 지키는 것"이 아니라 "컨테이너가 사라진 뒤에도 무슨 일이 있었는지 말할 수 있게 만드는 것"으로 옮겨간다. 로그를 중앙으로 빼서 정제하고, 탐지를 걸고, 무결하게 보존하는 것 — 그 한 줄기를 LogCenter로 엮어 두면, 파드가 사라진 자리에도 추적 가능한 증적이 남는다.