K10: Logging & Monitoring — 감사 로그 및 모니터링

보안의 마지막 단계는 ‘사고 탐지’와 ‘흔적 추적’입니다. 클러스터에서 어떤 사용자가, 어떤 명령을, 언제 실행했는지 기록하지 않는다면 사고가 발생해도 원인을 파악할 수 없습니다. K10은 쿠버네티스의 **Audit Logging(감사 로그)**을 활성화해 클러스터의 ‘CCTV’를 설치하는 과정을 다룹니다.

미션: 감사 로그 부재로 인한 가시성 결여

감사 로그가 활성화되지 않은 환경에서는 공격자가 비밀번호를 탈취하거나 권한을 수정해도 그 기록이 남지 않아, 나중에 사고를 인지하더라도 범인을 특정하기가 매우 어렵습니다.

1. 취약한 설정 (API 서버 실행 옵션)

# kube-apiserver 실행 옵션
# 🚨 위험: 감사 로그 정책 파일이 지정되어 있지 않음
--audit-log-path=""

분석: audit-log-path가 비어 있으면 쿠버네티스는 어떤 행위도 기록하지 않습니다. 공격자가 클러스터를 마음껏 휘젓고 다녀도 시스템은 아무런 증거를 남기지 않습니다.

2. 해결책 (로그 정책 적용)

# 1. 감사 로그 정책 정의 (policy.yaml)
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: Metadata # ✅ 개선: 리소스 접근 기록 남기기
    resources:
      - group: ""
        resources: ["secrets"] # 특히 민감한 Secret 접근은 더 세밀하게 기록

# 2. API 서버 실행 옵션 수정
--audit-policy-file=/etc/kubernetes/audit-policy.yaml
--audit-log-path=/var/log/kubernetes/audit.log # ✅ 개선: 로그 저장 경로 지정

분석: Metadata 수준 이상의 로그를 기록하도록 설정했습니다. 이제 모든 요청(특히 Secret 같은 민감 리소스 접근)은 로그 파일에 시간, 요청자, IP, 액션 내용과 함께 기록됩니다.

실습: 공격 → 방어 검증

1) 공격 — 감사 로그 없이 시크릿 조회

kubectl get secret db-secret -o yaml
# 조회는 성공하지만, audit.log에는 아무 흔적도 남지 않음

2) 방어 — 감사 정책 적용 후 재확인

kubectl apply -f policy.yaml  # API 서버 재시작 후 적용

kubectl get secret db-secret -o yaml
tail -f /var/log/kubernetes/audit.log
# {"user":{"username":"system:serviceaccount:default:app-sa"},"verb":"get",
#  "objectRef":{"resource":"secrets","name":"db-secret","namespace":"default"},
#  "requestReceivedTimestamp":"2026-07-04T09:12:03Z", ...}

‘누가’, ‘언제’, ‘무엇을’ 조회했는지 명확한 증거가 즉시 기록됩니다.

체크리스트

• --audit-log-path와 --audit-policy-file이 API 서버에 설정되어 있는가
• Secret, RBAC 리소스 등 민감한 대상은 Metadata보다 세밀한 레벨로 기록하는가
• 감사 로그가 로컬 디스크에만 머물지 않고 외부 SIEM/로그 시스템으로 전송되는가 (노드 장애 시 증거 유실 방지)
• PolicyViolation, Forbidden 같은 이벤트에 대한 알림이 실제로 담당자에게 도달하는가

“기록되지 않는 것은 존재하지 않는 것과 같다"는 말처럼, 감사 로그는 사고 대응의 첫 단추입니다.

10대 미션 정복 완료

K01부터 K10까지, 쿠버네티스 보안의 핵심 미션을 모두 살펴봤습니다.

공격자의 시각에서 취약점을 찾고, 운영자의 시각에서 이를 차단하는 관점을 순서대로 훈련한 셈입니다. 이 10대 미션은 OWASP Kubernetes Top 10 (2025) 기반 실습 프로젝트를 참고해 구성했습니다.