정책 기반 접근 제어
1️⃣ Content Trust + CVE Severity 정책 적용
Content Trust와 취약점 심각도(CVE Severity) 기반 정책은 이미지에 대한 신뢰성과 보안성을 강화하는 핵심 기능입니다.
Harbor에서는 다음과 같은 정책을 설정하여 보안 기준을 자동으로 강제할 수 있습니다:
- 서명되지 않은 이미지 거부
- 특정 CVE 심각도 이상의 이미지 Pull 제한
1. Content Trust (서명된 이미지만 허용)
Harbor는 Notary를 통해 서명된 이미지만 배포 가능하도록 설정할 수 있습니다.
📌 활성화 위치:
Administration → Configuration → Project → Enable Content Trust
┌──────────────┐
│ Docker CLI │
└──────┬───────┘
│
docker push --sign
│
┌──────▼───────┐
│ Harbor │
│ Notary Server│
└──────┬───────┘
│
이미지 서명 검증 후 저장
2. CVE 심각도 기반 이미지 Pull 제한
Harbor는 Trivy 또는 Clair 취약점 스캐너와 연동되어, 특정 수준 이상의 CVE가 있는 이미지를 Pull하지 못하게 막을 수 있습니다.
📌 활성화 위치:
Administration → Configuration → Project → Prevent Pull Based on Severity
✅ 예시: High 이상 취약점이 존재하는 이미지 Pull 금지
✅ 예제 정책 설정
항목 | 값 |
---|---|
Content Trust 활성화 | ✅ |
CVE 기반 Pull 제한 | ✅ (Critical 이상) |
스캐너 | Trivy |
2️⃣ + Tag Immutability 설정
Harbor에서는 이미지의 Tag를 **Immutable(불변)**하게 설정할 수 있습니다.
이는 기존 태그 위에 이미지를 덮어쓰지 못하도록 방지하여, 배포 시 안정성을 확보할 수 있게 해줍니다.
1. 기본 개념
docker tag myapp:1.0
docker push myapp:1.0 # 최초 Push 허용
docker push myapp:1.0 # ❌ Tag가 immutable이면 덮어쓰기 금지됨
2. 설정 방법
Projects → [프로젝트명] → Tag Retention → Create Rule
- 정규식으로 태그 패턴 설정 가능
- 예:
1.0*
태그를 immutable로 설정
✅ 실습 예제
Rule:
Tag Selector: 1.*
Action: Immutable
이 설정을 적용하면 1.0
, 1.1
, 1.2
같은 태그는 한번 Push 이후 수정이 불가능합니다.
3️⃣ + 프로젝트 단위 정책 구성 실습
Harbor는 각 Project 단위로 정책을 다르게 구성할 수 있습니다.
예를 들어, dev
, stage
, prod
각각 다른 보안 수준을 설정할 수 있습니다.
✅ 실습: prod
프로젝트의 보안 정책 설정
설정 항목 | 설정 값 |
---|---|
Content Trust | Enabled |
CVE Severity Block | High 이상 |
Tag Immutability | v* , release* |
Vulnerability Scanner | Trivy |
📌 설정 위치:
Projects → prod → Configuration
✅ 아키텍처 및 정책 적용 흐름도
[User] ── docker push myapp:v1 ──▶ [Harbor Project: prod]
│
┌────────────────────┼────────────────────────┐
│ │ │
[Notary 서명 검증] [Trivy 취약점 검사] [태그 불변성 체크]
│ │ │
거부/허용 CVE 심각도 확인 덮어쓰기 차단
🧠 정리 요약
항목 | 설명 |
---|---|
Content Trust | 서명된 이미지만 Pull 가능하도록 강제 |
CVE Severity 정책 | 심각한 취약점이 있는 이미지의 사용을 차단 |
Tag Immutability | 이미 Push된 태그는 변경 불가, 배포 안정성 확보 |
프로젝트 단위 정책 | 보안 수준을 프로젝트별로 다르게 적용 가능 (dev, stage, prod 구분 운영) |