🚨 쿠버네티스 Audit Log 정보의 오해, 한계점 그리고 대안 도구들

[cloudbro-radar]

K8s 운영 중 기본 Audit Log 정보에 대한 한계점과 이에 대한 대안을 공유드립니다. K8s Audit Log는 API 호출에 대한 기록이며, 런타임 행위에 대한 기록이 아닙니다. 보안 강화를 위해서는 Audit Log와 함께 별도의 런타임 보안 도구나 세션 레코딩 솔루션을 병행해야 합니다.

주요 한계점

1. kubectl exec의 사각지대: 사용자가 쉘(Shell)에 접속했다는 사실은 알 수 있지만, 그 안에서 구체적으로 어떤 명령어를 쳤는지는 기록되지 않습니다.
2. Port-forward 추적 불가: 포트 포워딩을 통해 내부로 접속한 트래픽의 구체적인 내용(Payload)을 파악하기 어렵습니다.
3. 인과관계 파악의 어려움: “파드 X가 이상 행동을 했다” → "누가 만들었나?"를 역추적할 때, 중첩된 컨트롤러(Deployment → ReplicaSet → Pod) 구조 때문에 **‘최초 원인 제공자(Root Cause)’**를 한눈에 파악하기 힘듭니다. (마치 systemd의 의존성 트리처럼 명확하지 않음)
4. Request/Response 재구성 불가: 구체적인 요청 및 응답 데이터를 복원하기가 매우 까다롭습니다.

대안으로 언급된 도구들

• 런타임 보안: Falco (컨테이너 내부 행위 탐지)
• 접근 제어 및 감사: Teleport, StrongDM (세션 레코딩 등)

[출처] Reddit - The heart of the internet