[CNCF 하드닝 08] 이미지 태그가 같으면 내용도 같을까요? Harbor 공급망 경계

Об этом предложении

기존 CNCF 시리즈 에서 Harbor의 이미지 저장소 역할을 살펴봤습니다. 이번 목표는 누가 올리는지, 배포할 내용이 무엇인지, 어떤 검사를 거쳤는지 를 분리해서 확인하는 것입니다. 저장소 로그인 성공만으로 이미지가 믿을 만해지지는 않습니다. 같은 이름으로 다른 내용이 들어오면 가상의 app:release 를 배포했다고 해 보겠습니다. 태그가 나중에 다른 이미지로 이동하면 같은 YAML을 재배포해도 내용이 달라질 수 있습니다. Harbor의 tag immutability는 선택한 태그 변경을 제한합니다. 배포 시 digest로 대상을 지정하면 내용 식별을 더 명확하게 기록할 수 있습니다. Tag immutability 전제는 Harbor 2.14 문서 기준의 프로젝트, TLS 신뢰 경로, 승인된 robot 계정, 실제 이미지와 스캔 도구입니다. 배포 주체와 이미지 업로드 주체를 분리하는 상황을 다룹니다. 각 단계는 서로 다른 질문입니다. 스캔이 끝났다는 사실과 신뢰한 빌드 주체의 서명이 확인됐다는 사실도 구분해야 합니다. robot 계정은 역할별로 프로젝트 robot은 해당 프로젝트의 자동 작업에 사용합니다. 배포용 계정에는 Pull만, 이미지 업로드 계정에는 필요한 Pull과 Push를 검토합니다. Harbor 2.14에서는 Push를 부여할 때 Pull도 함께 필요합니다. 만료·교체·비활성화 경로를 미리 정해 두세요. 프로젝트 robot 권한 역할 예시 권한 제외할 권한 배포 이미지 읽기 Pull Push·삭제·관리 CI 업로드 Pull + Push 프로젝트 관리 검토 담당 필요한 결과 조회 장기 robot 비밀 공유 robot 비밀은 secret store나 승인된 런타임 전달 경로로 다룹니다. 명령 인수·워크플로 로그·글 예제에 실제 값을 넣지 않습니다. 토큰을 만들었다는 기록과 배포가 어떤 토큰을 사용하는지는 별도로 점검해야 합니다. digest를 배포 정의에 남기기 다음은 Deployment의 spec.template.spec 에 들어가는 PodSpec 조각 입니다. registry와 digest는 합성이므로 그대로 pull할 수 없습니다. 실제 승인된 이미지의 digest와 이미 준비한 pull Secret 이름으로 교체해야 합니다. automountServiceAccountToken: false imagePullSecrets: - name: study-registry-pull containers: - name: app image: registry.example.com/study/app@sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef imagePullPolicy: IfNotPresent digest는 내용 식별입니다. 그 자체가 출처 신뢰나 취약점 없음의 증명은 아닙니다. IfNotPresent 는 로컬 캐시 사용을 허용하므로 registry에서 pull을 차단했어도 이미 캐시된 이미지나 실행 중인 워크로드를 자동으로 제거하지 않습니다. 실제 배포 경계는 별도 검토해야 합니다. 스캔과 서명 결과를 읽는 기준 Not Scanned , Unsupported , Scanning , 실패와 Complete 를 구분합니다. 스캐너가 지원하지 않는 대상은 취약점 0개와 같지 않습니다. 스캐너·DB 시점·대상 아키텍처·적용 임계값을 함께 기록하세요. Harbor 스캔 상태 Harbor는 Cosign·Notation 서명을 저장하고 content trust 기능을 제공하지만, 화면에 서명 accessory가 보이는 사실만으로 조직의 신뢰한 signer를 검증한 것은 아닙니다. 배포 전에 어떤 신원을 신뢰하는지 명시한 검증 정책이 필요합니다. 서명과 content trust 조회와 변경 검증 아래는 독자용 조회 안내입니다. 사용자 registry·클러스터에는 실행하지 않았습니다. kubectl get deployment app -n image-study -o jsonpath='{.spec.template.spec.containers[*].image}' kubectl get pods -n image-study -o jsonpath='{range .items[*]}{.metadata.name}{" "}{.status.containerStatuses[*].imageID}{"\n"}{end}' 템플릿과 실행된 imageID를 비교하고, Harbor UI에서 해당 digest의 스캔 상태·robot 권한·immutable 규칙을 조회합니다. tag와 digest의 관계, 다중 아키텍처 image index와 실제 플랫폼 이미지 차이도 남겨야 합니다. 실습에서 제한된 태그 재업로드가 거부되는지, pull 전용 계정의 Push가 거부되는지 확인합니다. 문제 발생 시 임계값을 무조건 낮추거나 TLS 검증을 끄지 않습니다. 되돌림은 이전에 검증한 digest와 배포 정의를 복원하는 것입니다. 그 digest의 현재 취약점 상태도 다시 검토하세요. 확인 문제 digest가 고정되면 취약점과 출처 검증도 끝난 것일까요? Unsupported 는 취약점이 없다는 결과일까요? registry pull 차단이 실행 중인 Pod까지 제거할까요? 답과 해설: 1. 내용 식별과 보안 검증은 별도입니다. 2. 검사하지 못한 상태입니다. 3. 실행 중이거나 캐시된 이미지는 별도 경계입니다. 오늘은 세 질문을 배포 기록에 넣고, 내일은 태그 이동 반례를 설명해 보세요. 일주일 뒤에는 robot 만료와 스캔 시점을 점검해 보세요. 버전과 검증 범위 2026-10-04 Harbor 2.14.0 문서 확인. 로컬 YAML과 digest 형식, tag-only 반례, Pull/Push 권한 분리·스캔 상태 분류를 검증했습니다. 실제 robot 인증·이미지 스캔·서명 검증·pull·배포는 실행하지 않았습니다.