The Conditions Under Which an Audit Trail Holds

한 줄 요약

감사 추적에는 실행한 내용의 식별자, 신뢰할 수 있는 생산 증거, 시점별 배포 기록이 필요합니다. 비밀값을 많이 저장한다고 증거가 좋아지는 것은 아닙니다.

왜 태그 하나로는 부족한가

태그는 다른 이미지로 이동할 수 있지만 digest는 내용의 식별자입니다. 따라서 원하는 배포를 digest로 고정하고 스캔·서명 대상과 연결하는 것이 좋습니다. digest 자체가 안전성, 작성자 또는 소스 커밋을 증명하지는 않습니다. Kubernetes 이미지

태그로 배포했다고 현재 이미지를 전혀 조사할 수 없는 것은 아닙니다. status.containerStatuses[].imageID에는 런타임이 식별한 이미지 정보가 있으며 선언한 이미지와 다를 수 있습니다. 형식과 digest의 의미는 런타임·이미지 종류에 맞게 확인합니다. 현재 조회는 이미 삭제된 파드의 과거 상태까지 복원하지 않으므로 배포 당시 식별자와 시각도 보존합니다. Kubernetes ContainerStatus 원본

어떻게 동작하나

네 가지 증거를 연결합니다

증거	확인할 것	단독으로 증명하지 못하는 것
이미지 digest	검증·배포 대상의 동일성	취약점 부재, 소스 커밋
이미지 서명	신뢰 정책에 맞는 서명자의 서명	그 서명자가 실제 빌더라는 사실
SBOM	구성 요소 목록과 대상 연결	목록의 완전성·작성자의 신뢰성
빌드 provenance	대상, 빌더, 입력과 빌드 과정	신뢰하지 않는 빌더의 정직성

이미지 서명과 SBOM 서명은 별개입니다. 이미지 서명이 유효해도 옆에 놓인 임의의 SBOM 파일까지 인증되는 것은 아닙니다. 예를 들어 SBOM을 담은 attestation은 서명 검증뿐 아니라 subject의 digest가 대상과 같은지, 기대한 predicateType인지 확인합니다. 빌드 provenance도 신뢰하는 빌더와 예상 소스·빌드 조건을 검증해야 합니다. SLSA 산출물 검증

Sigstore의 cosign verify와 cosign verify-attestation은 검증 대상이 다릅니다. 키리스 검증에서는 허용한 인증서 신원과 OIDC 발급자를 구체적으로 제한합니다. 암호학적으로 서명이 맞는다는 것과 우리 릴리스 주체가 서명했다는 것은 다른 판단입니다. Sigstore 검증 안내

스캔 보고서에는 대상 digest, 스캐너·취약점 DB 버전, 검사 시각과 예외를 묶습니다. 보고서 생성 성공만으로 배포 게이트가 되지는 않습니다. 기준 위반과 검사기 오류를 구분하면서 둘 다 적절히 배포를 멈추는지 확인합니다. 새 취약점이 발견되면 같은 이미지도 재평가해야 하므로 빌드 당시 통과를 영구 안전 판정으로 쓰지 않습니다.

Secret 본문을 감사 로그에 복제하지 않습니다

Metadata는 사용자·시각·리소스·동작 등의 기록을 남기되 요청·응답 본문은 남기지 않습니다. Request는 요청 본문, RequestResponse는 양쪽 본문을 포함합니다. Secret을 상세 수준으로 기록하면 민감한 내용이 로그로 복제될 수 있습니다. Kubernetes 감사 수준

Secret의 base64는 암호화가 아니므로 인코딩된 값도 노출입니다. Secret 조회 권한을 좁혔더라도 로그 독자에게 본문이 보이면 다른 경로로 유출됩니다. ConfigMap이나 Pod 명세에 비밀을 직접 넣는 일도 피해야 합니다. Secret 관리 원칙

다음은 본문을 남기지 않는 출발점 예시입니다. kubectl apply할 워크로드가 아니라 API 서버의 감사 정책 파일입니다. 실제 활성화에는 정책 파일과 로그·웹훅 저장 경로 설정이 필요하며 관리형 서비스는 제공자 설정을 확인합니다. 운영 설정을 그대로 교체하지 마세요.

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]
  - level: Metadata

처음에는 모든 요청을 Metadata로 기록합니다. 나중에 상세 규칙을 추가하더라도 민감 리소스 보호 규칙보다 앞에 광범위한 본문 기록 규칙을 넣지 않습니다. 첫 번째로 일치하는 규칙이 적용되므로 뒤의 보호 규칙으로 앞의 결정을 덮을 수 없습니다. 하위 리소스와 다른 API 그룹의 민감 데이터도 별도로 검토합니다. 감사 정책 API 계약

Metadata도 공개 로그가 아닙니다. 요청 URI나 감사 주석 등에 민감한 정보를 넣지 않고 로그 열람·반출 권한, 보존 기간, 무결성과 수집 실패 알림을 관리합니다. 본문 생략은 로그 전체의 자동 비밀 제거를 보장하지 않습니다.

현장에서 만나는 모습

예시 시나리오: 조사 담당자가 비밀값은 필요 없는데 누가 운영 Secret을 읽었는지는 알아야 합니다. 소유한 격리 환경에서 실제 자격 증명이 아닌 합성 표식으로 생성·조회·삭제 요청을 만들고, 해당 요청의 사용자·동작·대상·응답 결과가 남았는지 확인합니다. 동시에 requestObject와 responseObject, 합성 표식의 원문·인코딩 값이 없는지도 검사합니다. 기록이 비어 있으면 둘째 조건만 통과하므로 요청 증거의 존재를 먼저 확인해야 합니다.

수집 경로가 정상인 것도 별도 조건입니다. API 서버 로컬 파일에는 있지만 중앙 저장소에는 없다면 중앙 검색으로 사고를 조사할 수 없습니다. 알려진 시험 요청을 끝까지 찾아보는 것이 수집기 화면의 초록불보다 직접적인 증거입니다.

다음 퀴즈에서 확인할 것

정책 범위 누락, NetworkPolicy와 mTLS의 차이, Secret 감사 수준, digest와 provenance, SBOM 연결을 판단합니다.

실제로 확인한 범위

2026-09-11, 격리된 k3s v1.36.4+k3s1 탐침에서 합성 Secret의 생성·조회·삭제와 비허용 사용자 조회를 실행했습니다. Metadata에서는 네 요청의 증거만 남았고, 상세 규칙을 앞에 놓으면 합성 본문이 노출됐으며, 수정 후 다시 본문이 사라졌습니다. Secret 기록을 None으로 끈 경우에는 별도 /version 대조 요청은 기록되지만 Secret 증거가 없어 검증기가 실패했습니다.

저장소의 scripts/probe_cnpe_audit.py와 tests/test_cnpe_audit_probe.py에 재현과 반례 검사를 남겼습니다. 이 확인은 단일 노드의 로컬 감사 파일에 한정됩니다. 중앙 수집·로그 무결성·전체 민감 리소스 정책이나 운영 클러스터의 감사 설정을 검증·변경했다는 뜻은 아닙니다. 이어서 개인 VM에서 비밀 노출·Metadata 복구·None 증거 누락을 직접 재현하는 8단계 실습을 수행합니다. 수집 시점 발췌와 현재 API의 새 조회를 함께 확인하며, 이 자료가 중앙 감사 저장소의 무결성을 보장하지는 않습니다.