쿠버네티스 감사로그에 LLM 이상탐지 도입으로 달라지는 실무 리뷰 프로세스
배경과 문제정의
감사로그는 쿠버네티스 제어면에서 일어나는 모든 행위의 최종 기록입니다. 그러나 대규모 엔터프라이즈 환경에서는 초당 수백에서 수천 건의 이벤트가 발생하고, 규칙 기반 탐지는 새로운 패턴이나 조합형 공격에 취약합니다. 보안팀과 플랫폼팀은 “무엇을 먼저 볼 것인가”와 “어떤 맥락에서 위험한가”라는 질문에 반복적으로 시간을 쓰고 있습니다.
LLM을 이용한 이상탐지는 감사로그의 문맥(주체·행위·리소스·시점·이전 활동)을 통합적으로 해석해 의심스러운 패턴을 요약하고, 우선순위가 필요한 항목만 큐에 올리는 접근입니다. 핵심은 모델이 결정을 “대신” 하는 것이 아니라, 검토자가 결정을 “더 빠르고 일관되게” 내리도록 신뢰 가능한 신호를 제공하는 것입니다.
아키텍처 개요
표준 흐름은 다음과 같습니다. 1) kube-apiserver가 감사로그를 파일 또는 Webhook으로 출력, 2) 수집기(예: Fluent Bit/Fluentd)가 스트리밍 파이프라인(Kafka/HTTP)으로 전달, 3) 전처리 단계에서 PII/시크릿 마스킹과 피처 생성(동작 빈도, 과거 행위 대비 변화), 4) LLM 추론에서 정책 컨텍스트(사내 규정, 허용 목록)를 함께 주입해 위험 점수와 요약을 생성, 5) 결과를 저장(데이터 레이크/TSDB)하고 알림/티켓팅 시스템과 연동합니다.
모델 배치는 세 가지 선택지가 일반적입니다. a) 온프레미스 추론 서버(데이터 경계 강화), b) 가상 사설망을 통한 전용 엔드포인트(유출 통제와 관리 편의 균형), c) 공용 API(최단 구축). 데이터 민감도와 처리량, 팀의 운영 역량을 기준으로 결정하시면 됩니다. 어떤 경우든 구조화 출력(JSON 스키마), 재현 가능한 프롬프트 버전관리, 그리고 모델/프롬프트 변경 시 A/B 평가 경로를 갖춰야 합니다.
운영: 리뷰 프로세스 변화
도입 이후의 리뷰는 “전체 로그 열람”이 아니라 “우선순위 큐 중심”으로 전환됩니다. LLM이 사건을 요약하고 근거(예: 과거 대비 권한 상승, 근무시간 외 클러스터관리자 사용, 연속된 실패 후 성공한 exec)와 권장 조치(임시 계정 비활성화, 네임스페이스 격리)를 제시합니다. 검토자는 근거와 맥락을 보고 1차 조치 또는 추가 조사 여부를 결정합니다.
역할 정리는 다음 흐름이 실용적이었습니다. 플랫폼팀: 감사설정·파이프라인 신뢰성 SLO 관리. 보안팀: 탐지 기준, 허용 목록, 에스컬레이션 룰 유지. 서비스팀: 소유 네임스페이스 이슈의 원인 설명과 수정. 주간 운영 미팅에서는 상위 10개 오탐 유형을 제거하기 위한 규칙·프롬프트 보완을 합의합니다.
실무 팁입니다. 1) 초기 4주간은 “경고만 발송, 차단 없음”으로 운영해 신뢰를 확보합니다. 2) 우선순위 임계값은 알림 소음이 하루 당 담당자 1인 기준 10~20건을 넘지 않도록 역산합니다. 3) 주요 시나리오(권한 변경, 이미지 Pull from 외부 레지스트리, exec/port-forward 남용)는 별도 런북과 자동 티켓 템플릿을 준비합니다.
보안·비용 관점 팁
🚨 "Splunk" 관련 특가 상품 추천
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 일정액의 수수료를 제공받습니다.
보안 측면에서는 데이터 최소화가 핵심입니다. 감사로그에서 RequestObject/ResponseObject가 포함될 수 있으므로 시크릿, 토큰, 환경 변수 값은 수집기 단계에서 해시/마스킹하세요. 외부 추론을 사용할 경우 egress를 특정 엔드포인트로만 허용하고, 감사 이벤트 ID와 해시만 외부로 전송하는 방식을 권장합니다. 모델 출력은 서명하고, 원본 이벤트 해시와 상호 참조해 변조를 탐지합니다.
비용은 이벤트량과 토큰 사용량에 선형에 가깝습니다. 다음을 통해 60~85%까지 절감 가능합니다. 1) 이벤트 샘플링: 저위험 네임스페이스는 1/N 샘플. 2) 전처리 요약: JSON 전문 대신 핵심 필드/파생 피처만 입력. 3) 배치 추론: 10~50건 단위로 묶어 컨텍스트 공유. 4) 캐싱: 동일 패턴은 TTL 캐시를 사용. 5) 룰/LLM 하이브리드: 명백한 패턴(예: kube-system 내 delete pod)은 룰로 선필터링하고, LLM은 경계 사례만 처리합니다.
운영 지표는 다음을 권장합니다. 탐지 재현율(주 1회 샘플 평가), 오탐률, 평균 확인 시간(MTTReview), 알림당 비용, 파이프라인 지연 P95. 월 1회 모델/프롬프트 변경 심의와 롤백 플랜을 표준화하면 안정적으로 운영할 수 있습니다.
구현 예시
아래 예시는 감사정책과 간단한 파이프라인 스니펫입니다. 실제 환경에서는 네트워크·인증·리트라이·관측을 보강하시기 바랍니다.
# --- audit-policy.yaml (kube-apiserver --audit-policy-file) ---
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
# 읽기 트래픽은 메타데이터만
- level: Metadata
verbs: ["get", "list", "watch"]
# 쓰기 계열은 요청/응답 포함
- level: RequestResponse
verbs: ["create", "update", "patch", "delete"]
omitStages: ["RequestReceived"]
# 민감 리소스 접근 강화 로깅
- level: RequestResponse
resources:
- group: ""
resources: ["secrets", "configmaps"]
- group: "rbac.authorization.k8s.io"
resources: ["clusterroles", "clusterrolebindings", "roles", "rolebindings"]
- group: ""
resources: ["pods/exec", "pods/portforward"]
namespaces: ["*"]
# 인증/토큰 관련
- level: RequestResponse
resources:
- group: "authentication.k8s.io"
resources: ["tokenreviews"]
---
# --- stream_consumer.py (Kafka/HTTP 소비자) ---
import json, os, re, time
from datetime import datetime
from typing import Dict, Any
LLM_ENDPOINT = os.getenv("LLM_ENDPOINT") # 내부/외부 추론 엔드포인트
RISK_THRESHOLD = float(os.getenv("RISK_THRESHOLD", "0.65"))
def redact(e: Dict[str, Any]) -> Dict[str, Any]:
# 간단한 마스킹: 토큰/시크릿/IPv4
s = json.dumps(e)
s = re.sub(r'"token"\s*:\s*".+?"', '"token":"***"', s)
s = re.sub(r'"data"\s*:\s*".+?"', '"data":"***"', s)
s = re.sub(r'(\d{1,3}\.){3}\d{1,3}', '0.0.0.0', s)
e2 = json.loads(s)
# 최소필드만 유지: 성능·프라이버시 절충
keep = ["user", "verb", "stage", "requestURI", "namespace", "objectRef",
"sourceIPs", "userAgent", "responseStatus", "requestObject", "annotations", "auditID", "requestReceivedTimestamp"]
return {k: e2.get(k) for k in keep}
SYSTEM_PROMPT = """당신은 쿠버네티스 감사로그 분석가입니다.
정책:
- 근무시간(09:00-19:00) 외 cluster-admin 사용은 고위험
- secrets 접근은 승인된 SA만 허용
- 10분 내 연속된 실패 후 성공한 pods/exec는 의심
구조화 JSON으로만 응답:
{"score": 0~1, "category": "...", "reason": "...", "recommended_action": "..."}"""
def build_prompt(event: Dict[str, Any], stats: Dict[str, Any]) -> str:
return f"""이벤트:{json.dumps(event, ensure_ascii=False)}
이전 24시간 통계:{json.dumps(stats, ensure_ascii=False)}"""
def call_llm(prompt: str) -> Dict[str, Any]:
# 의도적으로 벤더 중립적인 예시
import requests
resp = requests.post(LLM_ENDPOINT, json={
"model": "policy-anomaly",
"system": SYSTEM_PROMPT,
"input": prompt,
"response_format": {"type": "json_object"}
}, timeout=10)
out = resp.json()
return out
def compute_stats(key: str) -> Dict[str, Any]:
# 팀 환경에 맞게 캐시/스토리지에서 불러오기
return {"past_exec_failures_10m": 3, "user_past_week_actions": 124}
def handle_event(raw: Dict[str, Any]):
e = redact(raw)
stats = compute_stats(e.get("user", ""))
prompt = build_prompt(e, stats)
result = call_llm(prompt)
score = float(result.get("score", 0))
severity = "high" if score >= 0.8 else "medium" if score >= RISK_THRESHOLD else "info"
finding = {
"auditID": e.get("auditID"),
"ts": e.get("requestReceivedTimestamp", datetime.utcnow().isoformat()),
"score": score,
"severity": severity,
"category": result.get("category"),
"reason": result.get("reason"),
"recommended_action": result.get("recommended_action"),
"event": e
}
if severity in ["high", "medium"]:
notify(finding)
persist(finding)
def notify(f):
# Slack/이메일/티켓 생성 등
print("[ALERT]", f["severity"], f["reason"])
def persist(f):
# 데이터 레이크/TSDB에 저장
pass
# 메시지 루프(의사 코드)
def main_loop():
while True:
raw = get_next_event() # Kafka/HTTP 등에서 수신
try:
handle_event(raw)
except Exception as ex:
log_error(ex)
# main_loop()
FAQ
Q. 룰 기반과 LLM 기반을 어떻게 조합하면 좋을까요?
A. 고정 패턴(예: kube-system 네임스페이스의 삭제 요청)은 룰로 선차단/선탐지하고, 컨텍스트 해석이 필요한 경계 사례만 LLM으로 넘기면 오탐과 비용을 동시에 줄일 수 있습니다.
Q. LLM의 환각(근거 없는 판단)을 어떻게 완화하나요?
A. 구조화 출력(JSON 스키마 강제), 근거 요구(참조 필드명 포함), 정책 문서의 버전 고정, 샘플 이벤트 few-shot 제공, 그리고 모델·프롬프트 변경 시 오프라인 골든셋 평가를 필수로 운영합니다.
Q. 개인정보나 시크릿이 외부로 전송되는 것을 피하려면?
A. 수집기 단계에서 마스킹/해시를 적용하고, 외부 추론 시 원문 대신 축약된 특징량만 보냅니다. 가능하면 온프레미스 추론을 사용하고, 데이터 전송과 저장에 대한 감사 로그를 별도로 남기세요.
Q. 초기 임계값은 어떻게 정하나요?
A. 2주간의 파일럿에서 알림당 검토 시간과 오탐률을 측정해 담당자 1인당 일일 처리 가능량 내로 역산합니다. 일반적으로 score 0.6~0.7 사이에서 시작해 주 단위로 조정합니다.
Q. 실제 차단까지 자동화해야 할까요?
A. 시작 단계에서는 알림과 티켓 생성까지만 권장합니다. 충분한 신뢰도가 확보되면 특정 카테고리(예: 만료된 자격증명 사용)부터 점진적으로 자동 조치로 확장하는 방식이 안전합니다.
엔터프라이즈 팀 리더 경험담
에피소드 1: 감사로그 요약으로 바뀐 변경 리뷰
도입: 여러 팀이 쿠버네티스 리소스 변경(PR)과 배포 승인 시 감사로그를 참고하지만, 로그가 방대해 핵심 포인트만 추려보는 데 시간이 많이 걸렸습니다. LLM 기반 이상탐지를 붙여 변경 영향 요약과 위험 가설을 자동 생성하도록 시작했습니다.
문제: 초기에는 경고가 과다했고, 리뷰어가 경고를 다시 검증하느라 되려 시간이 늘었습니다. 특히 정상적인 프로브 호출을 데이터 유출 시도로 오판하는 사례가 반복됐습니다.
시도: 시스템 호출·헬스체크 패턴에 대한 화이트리스트, 시간대·배포 창정보와 결합한 프롬프트 가드레일, 정책 베이스라인(RBAC·네트워크 정책) 검색을 통한 근거 제시를 추가했습니다. 리뷰 체크리스트에는 “모델 근거에 해당 감사 이벤트 원문 링크 포함”을 의무화했습니다.
결과/교훈: 리뷰 리드타임이 22% 감소했고, 리뷰어가 먼저 보는 것은 요약이 아니라 “어떤 감사 이벤트가 비정상인가”에 대한 근거 스니펫이 되었습니다. 다만 초기에 과잉 탐지로 신뢰를 잃을 뻔했고, 도메인 규칙(시스템 네임스페이스, 프로브 트래픽 등)의 명시적 정제가 선행돼야 한다는 교훈을 얻었습니다.
에피소드 2: 주말 사고 대응에서 드러난 상호보완
도입: 주말 야간에 특정 서비스어카운트로 노드 수준 권한이 활용된 정황이 있었습니다. 평소 같으면 감사로그 필터링과 타임라인 정리에만 시간이 소요됩니다.
문제: LLM은 “이례적인 verb-resource 조합과 빈도 급증”을 지적했지만, 실제 운영 변경과 우발적 스케일링 이벤트가 겹쳐 맥락 혼선이 있었습니다.
시도: 감사 이벤트를 배포 캘린더·변경 승인 기록과 자동 상관 분석하도록 파이프라인을 확장했습니다. 또한 권한 그래프(RBAC 바인딩)에서 잠재적 승격 경로를 시각화해 리뷰어가 모델 추론을 교차 검증했습니다.
결과/교훈: 원인 파악과 차단 조치까지의 MTTR이 18% 감소했습니다. 반면, 네임스페이스 접두 규칙이 팀별로 제각각이라 모델이 횡이동 신호를 놓친 실패가 있었고, 이후 리소스 네이밍 표준화와 라벨 일관성을 강제하는 정책을 먼저 정비했습니다. 모델의 통찰은 유용했지만, 운영 메타데이터의 정합성이 담보돼야 성과가 확실해진다는 점을 확인했습니다.
에피소드 3: 리뷰 거버넌스 재정립
도입: 이상탐지 결과를 정기 변경심의·접근권한 리뷰에도 적용했습니다. 초기에는 “자동화의 판단을 어디까지 신뢰할 것인가”가 논쟁거리였습니다.
문제: 일부 리뷰어가 모델 요약만 보고 승인하려는 경향이 생겼고, 반대로 몇몇 팀은 모델이 자주 경고하는 개발 클러스터 신호를 습관적으로 무시했습니다.
시도: 이중 트랙을 도입했습니다. 1차는 모델 기반 이상 우선순위화, 2차는 사람이 근거 스니펫과 정책 베이스라인 차이를 확인하는 절차입니다. 오판 사례는 “왜 틀렸는가”를 태깅해 재학습 말고 규칙·프롬프트 레벨에서 피드백 순환을 구축했습니다.
결과/교훈: 리뷰 품질이 팀 간 균질해졌고, 승인 회의는 개별 로그 낭독보다 “정책과 행위의 괴리”에 집중하게 되었습니다. 다만, 자동화의 권위를 빌린 의사결정은 쉽게 굳어진다는 점을 경계하게 되었고, 최종 승인은 반드시 사람이 “모델 근거를 반박할 수 있는가”를 스스로 점검하는 문화를 정착시켰습니다.
결론
LLM 기반 이상탐지는 감사로그의 해석 비용을 줄이고, 팀이 집중해야 할 사건을 선별하는 데 유용합니다. 핵심은 데이터 최소화, 구조화 출력, 하이브리드 탐지, 운영 지표 기반의 지속 개선입니다. 이 네 가지를 지키면 오탐과 비용을 통제하면서 의미 있는 신호를 얻을 수 있습니다.
다음 액션을 제안드립니다. 1) 상위 3개 시나리오(권한 변경, secrets 접근, exec 남용)에 대한 파일럿을 2주간 운영, 2) 골든셋과 프롬프트/모델 버전관리를 레포지토리에 정착, 3) 주간 운영 미팅에서 임계값·허용 목록·런북을 재조정, 4) 8주 내 온프레미스 추론 또는 전용 엔드포인트 전환 여부를 의사결정하십시오. 이 일정을 기준으로 분기 내 실사용 단계에 도달할 수 있습니다.
댓글
댓글 쓰기