비밀은 지우고 사건은 남기는 감사 정책

목표

개인 VM의 진짜 k3s에서 합성 비밀 노출 → Metadata 복구 → None 증거 누락 → 최종 복구를 수행합니다.

왜 중요한가

정책이 있다는 것만으로 안전한 감사 추적이 생기지는 않습니다. 실제 요청이 남는지와
본문이 복제되지 않는지를 함께 검사해야 합니다. CNPE의 감사 추적 역량 일부를 연습하며
공식 시험 문제를 복제하거나 보안 영역 전체를 다룬다는 뜻은 아닙니다.
Kubernetes 리소스·RBAC·JSON·jq와 systemd 기초가 필요합니다.

준비된 것

Ubuntu 24.04 개인 VM, k3s v1.36.4+k3s1, cnpe-audit Namespace와 합성 canary,
합성 Secret의 상세 감사 기록이 준비됩니다. 첫 준비는 수분 걸릴 수 있습니다.
모든 상대 경로는 /root/cnpe-audit 아래입니다. drop-in의 전체 경로는
/etc/rancher/k3s/config.yaml.d/95-cnpe-audit.yaml입니다.
이것은 API 서버 정책 파일이지 kubectl apply할 리소스가 아닙니다.

75분 실습이므로 기본 60분 세션에서 ＋시간으로 연장하세요. 세션 종료 시 파일과 VM이
사라집니다. 필요한 보고서는 값 노출 여부를 검토한 뒤 별도로 보관하세요.
systemctl restart는 이 VM 안에서만 사용합니다. 호스트 클러스터나 다른 사람의 세션은
건드리지 않으며 실제 자격 증명·개인정보를 넣지 않습니다.

단계

1. 자기 VM의 API와 감사 환경을 확인한다 — kubectl --kubeconfig=/etc/rancher/k3s/k3s.yaml get nodes로 현재 호스트 하나인 클러스터를 확인하세요. Namespace cnpe-audit는 이 실습 전용입니다. 환경에는 합성 Secret 상세 수집이 켜져 있습니다. 다른 클러스터의 kubeconfig나 실제 비밀을 가져오지 마세요.
2. 값이 아닌 노출 여부를 보고한다 — 준비된 unsafe-case.json과 unsafe-events.jsonl을 읽어 unsafe-report.json을 작성하세요. requests는 해당 Secret의 ResponseComplete 이벤트 수, body_present는 requestObject 또는 responseObject 키 존재 여부, marker_exposed는 case의 marker 원문 또는 base64 노출 여부, control_present는 case.control_uri의 200 대조 기록 존재 여부입니다. safe_to_accept는 네 Secret 요청이 존재하고 본문·표식이 없으며 대조 기록이 있는 경우만 true입니다. 원본 비밀값을 보고서에 복사하지 마세요.
3. 본문을 빼되 추적은 남기는 정책을 쓴다 — safe-policy.json에 apiVersion audit.k8s.io/v1, kind Policy, omitStages [RequestReceived]를 쓰세요. rules는 두 개입니다. 첫 규칙은 level Metadata, namespaces [cnpe-audit], resources [{group: 빈 문자열, resources: [secrets]}]이며 두 번째는 조건 없는 level Metadata입니다. 이 실습은 이 제한된 정책 계약을 사용하며 범용 정책 편집기가 아닙니다.
4. 정책 파일과 실행 중인 API를 연결한다 — 95-cnpe-audit.yaml을 JSON 문법으로 작성하세요. 유일한 키 kube-apiserver-arg+의 목록에 audit-policy-file=/root/cnpe-audit/safe-policy.json, audit-log-path=/root/cnpe-audit/runtime.jsonl, audit-log-mode=blocking, audit-log-maxsize=5, audit-log-maxbackup=1, audit-log-maxage=1을 넣으세요. 개인 VM 안의 k3s를 재시작하고 /readyz가 ok인지 확인합니다. 채점은 새 합성 canary 조회의 실제 감사 수준도 검사합니다.
5. 생성·조회·거절·삭제를 실제로 보낸다 — 아래 참고의 수집 명령 형식에서 단계 인자를 safe로 선택해 실행하세요. 수집기는 이번 UUID의 합성 Secret 생성·관리자 조회·권한 없는 대리 사용자 조회·삭제, 별도 /version 대조 요청을 수행합니다. safe-case.json, safe-events.jsonl, safe-origin.jsonl이 만들어져야 합니다. 요청 네 개는 201·200·403·200이고 Metadata 본문은 없어야 합니다.
6. 빈 기록을 통과시키지 않는 요약을 만든다 — safe-case.json과 safe-events.jsonl에서 2단계와 같은 다섯 필드를 계산하여 safe-report.json에 저장하세요. 수집 시점 원본 발췌와 분석 파일을 함께 보존합니다. 이 보고서는 이 수집기의 제한된 시나리오 요약이지 임의 감사 로그를 승인하는 범용 보안 게이트가 아닙니다.
7. None으로 숨긴 사건을 실패로 분류한다 — none-policy.json을 3단계 정책과 같게 만들되 첫 Secret 규칙만 None으로 바꾸세요. drop-in의 정책 경로만 이 파일로 바꾸고 개인 k3s 재시작·준비 확인 후 collect none을 실행합니다. none-report.json에 같은 다섯 필드를 계산하세요. Secret 기록은 0, 대조 기록은 존재하며 safe_to_accept는 false여야 합니다. 감사 기능 전체가 꺼진 경우는 이 반례와 다릅니다.
8. 안전 정책을 복구하고 새 증거를 남긴다 — drop-in을 safe-policy.json으로 되돌리고 개인 k3s를 재시작하세요. collect final로 새 요청을 만들고 final-report.json을 계산합니다. 예전 safe 보고서를 복사하지 마세요. 채점은 새 요청과 현재 API의 canary 조회를 함께 확인합니다. 이후 다른 실습을 시작하지 말고 이 개인 세션을 종료하면 됩니다.

참고

수집 명령 형식은 python3 /opt/fixtures/cnpe-audit-lab.py collect <단계>입니다.
<단계>를 과제에서 지정한 safe, none, final 중 하나로 바꾸세요.
collect는 명시적으로 합성 Secret을 생성·삭제하는 수집 명령입니다. check는 파일과
현재 API를 읽으며 canary를 변경하지 않습니다. 수집 실패 시 이전 증거가 새 요청으로
오인되지 않도록 요청 식별자를 먼저 갱신합니다. origin 발췌를 따로 저장하므로 원본
로그가 순환해도 이전 단계는 재채점할 수 있습니다. 학생 root에 대한 위변조 방지나
중앙 수집·불변 저장소·전원 장애·모든 민감 리소스 보호의 증거는 아닙니다.
마지막 안전 정책으로 복구한 뒤 전체 채점을 하세요. 7단계 None이 활성화된 동안
현재 안전 상태를 요구하는 4단계는 실패하는 것이 정상입니다.

공식 문서

• https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/
• https://docs.k3s.io/installation/configuration
• https://training.linuxfoundation.org/certification/certified-cloud-native-platform-engineer-cnpe/

단계 8개

1. 자기 VM의 API와 감사 환경을 확인한다
2. 값이 아닌 노출 여부를 보고한다
3. 본문을 빼되 추적은 남기는 정책을 쓴다
4. 정책 파일과 실행 중인 API를 연결한다
5. 생성·조회·거절·삭제를 실제로 보낸다
6. 빈 기록을 통과시키지 않는 요약을 만든다
7. None으로 숨긴 사건을 실패로 분류한다
8. 안전 정책을 복구하고 새 증거를 남긴다