감사관이 왔는데 '켜져 있다'는 증거가 없다

목표

여러 보안 통제 항목(익명 접근 차단, Pod Security 강제, 서비스어카운트 토큰 자동 마운트 해제, 자원 할당량)을
클러스터에서 직접 확인하고, 그 결과를 통제 ID 별 pass/fail 리포트와 결함 목록으로 남깁니다.

왜 중요한가

CIS Kubernetes Benchmark, NSA/CISA 강화 가이드, SOC 2·ISO 27001 같은 프레임워크는 결국
"이 통제가 켜져 있는가" 를 묻는 질문 목록입니다. 감사에서 문제가 되는 건 통제가 없는 경우보다
켜져 있다고 적었는데 실제로는 꺼져 있는 경우입니다. 그래서 리포트의 한 줄 한 줄은 설정 파일이나
기억이 아니라, 지금 클러스터가 돌려주는 답(auth can-i, 오브젝트 필드, 라벨)에서 나와야 합니다.

또 강화한 곳만 보고 끝내면 안 됩니다. 아무도 손대지 않은 default 네임스페이스처럼 **통제 밖에 남은
자리**를 찾아 결함으로 기록하는 것이 컴플라이언스 점검의 절반입니다.

단계

1. 점검 대상 네임스페이스 kcsa-comp 를 만듭니다.
2. system:anonymous 가 시크릿을 list 할 수 있는지 물어보고 anon.txt 에 기록합니다.
3. kcsa-comp 에 pod-security.kubernetes.io/enforce=restricted 라벨을 붙입니다.
4. restricted 요건을 모두 갖춘 파드 hardened 를 만듭니다.
5. default 서비스어카운트의 토큰 자동 마운트를 끕니다.
6. ResourceQuota quota 로 네임스페이스 자원 상한을 겁니다.
7. 네 통제 항목의 실제 결과를 compliance.csv 리포트로 씁니다.
8. enforce 라벨이 없는 네임스페이스를 찾아 gaps.txt 에 결함으로 기록합니다.

참고

• 산출물은 모두 /root/kcsa-comp/ 아래에 둡니다. 채점기는 파일의 값을 클러스터 실제 상태와 다시 대조합니다.
• kubectl auth can-i ... --as=<사용자> 는 그 주체가 SelfSubjectAccessReview 를 만들 수 있을 때만 답합니다. 익명 사용자처럼 그조차 못 하는 주체는 관리자가 SubjectAccessReview 로 대신 묻습니다.
• kubectl get ns -L <라벨키> 로 네임스페이스별 라벨을 한 표로 볼 수 있습니다.
• 공식 문서: [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) ·

[감사(Auditing)](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/) ·
[인가와 SubjectAccessReview](https://kubernetes.io/docs/reference/access-authn-authz/authorization/).

단계 8개

1. 감사 대상 네임스페이스를 세우다
2. 로그인하지 않은 누군가가 시크릿을 볼 수 있는가
3. 네임스페이스에 restricted 문지기를 세우다
4. restricted 기준을 통과하는 파드를 들이다
5. 쓰지도 않는 토큰이 모든 파드에 꽂힌다
6. 한 팀이 클러스터를 다 먹지 못하게
7. 감사관에게 낼 통제 항목 리포트
8. 기본 네임스페이스는 누가 지키고 있나