팔로우 Kubernetes 감사 로그가 어디에 저장되는지는 컨트롤 플레인을 누가 운영하는지에 따라 다릅니다. 자가 관리 클러스터에서는 컨트롤 플레인 노드에 JSON-lines 파일로, –audit-log-path가 가리키는 경로에 저장됩니다. EKS에서는 CloudWatch Logs에, AKS에서는 Log Analytics 작업 영역 또는 저장소 계정에, GKE에서는 Cloud Audit Logs에 저장됩니다. 모든 곳에서 공통적인 것은 감사 로그 기능을 켜야 한다는 점입니다. 자가 관리 클러스터와 EKS에서는 누군가가 이를 활성화하기 전까지는 꺼져 있습니다.
감사 로그는 Kubernetes API에 대한 모든 요청을 기록합니다: 어떤 사용자가 kubectl exec을 실행하여 어떤 포드에 들어갔는지, 누가 어떤 비밀을 읽었는지, 누가 자신을 cluster-admin에 바인딩했는지를 기록하는 것입니다. Prime Core는 이러한 Kubernetes 감사 데이터에 대해 93개의 탐지 규칙을 가지고 있으며, 이것은 220개의 MITRE ATT&CK 기술에 매핑됩니다. 그 중에는 실행 중인 컨테이너에 exec 진입하기(T1609), 불량 컨테이너 배포하기(T1610), 컨테이너 API를 통해 자격 증명을 읽기(T1552.007) 등이 포함됩니다.
시작하기 전에
활성화되어 있습니까?
| 플랫폼 | 확인할 곳 |
|---|---|
| 자가 관리(kubeadm 및 유사한 방법) | –audit-policy-file과 –audit-log-path가 API 서버에 있으며; kubeadm을 사용하는 경우 /etc/kubernetes/manifests/kube-apiserver.yaml에 있습니다. |
| EKS | 클러스터 → 가시성 → 컨트롤 플레인 로깅, “감사” 로그 유형 |
| AKS | 클러스터의 진단 설정, kube-audit 또는 kube-audit-admin 카테고리 |
| GKE | 관리자 활동에는 기본적으로 켜져 있습니다; Kubernetes의 데이터 접근 로깅은 선택 사항입니다 |
켜져 있지 않았다면, 과거에 내보낼 것이 없으며, 이 가이드의 나머지는 다음 번에 관한 것입니다.
상세 내용은 정책에 따라 다릅니다. 메타데이터 수준에서는 누가 어느 객체에 무엇을 했는지 알 수 있습니다. 요청 또는 요청 응답 수준에서는 본문도 보입니다. 예를 들어, 특권을 요청한 포드 사양입니다: true. 무엇을 가지고 있는지 알기 전에 찾으러 가지 마세요.
볼륨을 예상하세요. 컨트롤러와 서비스 계정은 API와 끊임없이 대화합니다. AKS에서는 kube-audit-admin이 읽기 전용 get 및 list 호출을 제외하여 크기를 유지하지만 비밀 읽기 또한 숨깁니다.
내보내기
자가 관리 클러스터, 컨트롤 플레인 노드에서:
# 경로를 먼저 확인합니다
sudo grep -- '--audit-log-path' /etc/kubernetes/manifests/kube-apiserver.yaml
sudo cat /var/log/kubernetes/audit/audit.log > k8s_audit.jsonl
회전된 파일은 (–audit-log-maxbackup에서) 이름에 타임스탬프가 포함되어 있으며, 그 옆에 있습니다. 창이 과거로 확장되는 경우 포함하세요.
EKS, CloudWatch Logs에서:
aws logs filter-log-events --log-group-name /aws/eks/my-cluster/cluster
--log-stream-name-prefix kube-apiserver-audit
--start-time $(date -d '2026-10-19T00:00:00Z' +%s000) --end-time $(date -d '2026-10-20T00:00:00Z' +%s000)
--output json | jq -c '.events[].message | fromjson' > eks_audit_1019.jsonl
각 CloudWatch 이벤트는 감사 항목을 문자열로 감싸고 있습니다; fromjson은 이를 벗겨냅니다. date -d 문법은 GNU입니다; macOS에서는 밀리초 타임스탬프를 다른 방법으로 계산하세요.
AKS, Log Analytics에서(리소스 특정 테이블):
az monitor log-analytics query -w
--analytics-query "AKSAuditAdmin | where TimeGenerated between (datetime(2026-10-19) .. datetime(2026-10-20))"
--output json > aks_audit_1019.json
GKE, Cloud Audit Logs에서:
gcloud logging read 'resource.type="k8s_cluster" AND logName:"cloudaudit.googleapis.com" AND timestamp>="2026-10-19T00:00:00Z" AND timestamp<"2026-10-20T00:00:00Z"'
--project=my-project --format=json | jq -c '.[]' > gke_audit_1019.jsonl
찾아야 할 것
| 요청 | 이유 |
|---|---|
| create on pods/exec (objectRef.subresource: exec) | 실행 중인 컨테이너 내부에 셸을 열었습니다 |
| cluster-admin으로의 ClusterRoleBinding 생성 | 전체 권한 제어로의 권한 상승 |
| 비정상적인 ID로 시크릿을 get 또는 list | 자격 증명 수집 |
| privileged, hostPath 또는 hostNetwork로 생성된 포드 | 노드로 탈출하기 위한 한 걸음 |
| user.username: system:anonymous with a 2xx response | 작동하지 않아야 되는 익명 접근 |
| 하나의 서비스 계정에서 403 폭발적인 요청 | 권한을 확인하는 도난 당한 토큰 |
LogTotal에 업로드하여 정리 및 검토
- 업로드. 열기 logtotal.com 하고 .jsonl 파일을 드롭합니다.
- 정리. [what gets masked: usernames, service account names, source IPs, namespaces, object names]. Look it over before you continue.
- 검토.
문제가 발생할 때
| 증상 | 가능성이 높은 원인 | Fix |
|---|---|---|
| 컨트롤 플레인에 감사 파일 없음 | API 서버에 감사 정책이 구성되지 않음 | 예상됨; 미래를 위해 구성하세요 |
| EKS 로그 그룹 또는 감사 스트림 없음 | “감사” 컨트롤 플레인 로그 유형이 활성화되지 않음 | 미래를 위해 활성화하세요 |
| 각 라인은 긴 이스케이프된 문자열 | CloudWatch 래핑 | fromjson으로 위에서 언급한 대로 벗기세요 |
| 누가 포드를 변경했는지는 알지만 어떻게 변경했는지는 모릅니다 | 정책이 메타데이터 수준에 있음 | 민감한 리소스에 대한 수준을 높이세요 |
| AKS 데이터에서 시크릿 읽기 없음 | kube-audit-admin은 get 및 list를 제외함 | 필요하다면 kube-audit를 수집하세요 |
FAQ
컨테이너 로그가 충분하지 않나요?
아니오. 컨테이너 로그는 애플리케이션이 출력한 내용을 보여줍니다. 감사 로그는 사람과 서비스 계정이 클러스터에 한 일을 보여줍니다. 다른 질문, 다른 로그입니다.
관리형 클러스터에서 감사 파일을 읽을 수 있나요?
아니오. EKS, AKS 및 GKE에서는 컨트롤 플레인 노드에 대한 접근 권한이 없습니다. 제공자의 로깅 서비스가 유일한 경로입니다.
