service-catalog/images/cnpg-postgresql/README.md

cnpg-postgresql — CloudNativePG PostgreSQL 자체 빌드

CNPG 오퍼레이터가 관리하는 PostgreSQL 인스턴스 이미지를 직접 빌드한다. manifests/helm/cnpg-cluster/1.0.0/custom-values.yaml 의 imageName 이 이 산출물을 가리킨다.

security-catalog 프로젝트에서 포팅했다. 목표 정의·이미지 선택 규칙·후보 비교 실측·이미지 채택 결정·빌드 자동화(CI) 문서(doc/cve-zero-pipeline.md, doc/image-selection.md, doc/analysis/cnpg-image-vuln-comparison.md, doc/decisions/0001-cnpg-postgresql-image.md, doc/architecture/build-pipeline.md)는 security-catalog 프로젝트에 있고 dip-catalog 에는 아직 이관되지 않았다.

자체 빌드는 대응 우선순위 3번이다. 상위 태그 교체·베이스 OS 교체로 목표를 만족할 수 있으면 그 쪽을 쓴다. 자체 빌드는 업스트림 서명·provenance·SBOM attestation 을 잃고 재빌드 책임을 지는 선택이다.

---

왜 자체 빌드하나

업스트림 ghcr.io/cloudnative-pg/postgresql:18.4-standard-trixie 는 실효 CRITICAL/HIGH 23건을 갖고 있고, 전부 수정 버전이 없다(Debian unimportant 9 / no-dsa 7 / postponed 3 / 미분류 4). SUSE 는 같은 CVE 들을 이미 백포트했다 — 베이스 OS 를 바꾸면 벤더 판정이 달라진다.

단, 수치가 낮아진 것이 실제 개선인지 벤더 미평가인지 반드시 구분해야 한다. cve-gate.py 의 교차 검증(--crossref)이 이를 돕는다. security-catalog 의 scan-sbom.sh 가 제공하던 커버리지 자가진단(CoverageProbe)은 dip-catalog 의 scan-sbom.sh 에는 아직 없다(doc/sbom-pipeline.md 참고).

베이스 OS

이 이미지는 SUSE BCI 15.7 로 빌드됐다(security-catalog 프로젝트 ADR, 미이관).

파일	베이스	패키지 관리자	측정 가능성
suse.Dockerfile	registry.suse.com/bci/bci-base:15.7	zypper + PGDG rpm	✅ trivy 로 완전 측정

ubuntu:24.04 기반 빌드(후보 B)는 security-catalog 프로젝트에서 검토 후 제거됐다 — 카탈로그가 채택하지 않아 재빌드되지 않은 채 낡아가고 있었다(빌드 하루 만에 findings 38 → 46). 관련 실측은 이관되지 않았다.

업스트림과의 차이

원칙: 업스트림 Dockerfile 과의 차이를 최소로 유지한다. 패키지 구성·uid·확장 목록을 임의로 줄이면 오퍼레이터가 이미지에 기대하는 조건이 깨진다.

suse.Dockerfile 은 업스트림 CNPG(Debian/apt/PGDG-deb)를 SUSE(zypper/PGDG-rpm)로 이식한 것이라 저장소 설정·패키지명·경로가 전부 다르다. 대응 관계는 파일 상단 주석 참고.

patched 단계의 zypper update -y 가 실제로 기여한 몫: 베이스 이미지는 주기적으로만 재빌드되므로 배포판 아카이브보다 뒤처져 있다. 이 단계가 없으면 그 시점의 미패치 취약점이 그대로 남는다 — 자동 재빌드가 필요한 이유가 이것이다.

업스트림 빌드 레시피 변경 점검 (수동, 자동화 대상 아님)

cloudnative-pg/postgres-containers 저장소가 자체 Dockerfile 구조를 바꾸면(새 확장, 새 하드닝 단계 등) 이 포트도 따라가야 한다. CI 로 자동 감지하지 않는다 — 배포판이 달라(Debian vs SUSE) 의미 있는 diff 가 안 나온다.

권장 점검 주기: CNPG 마이너 릴리스마다. 업스트림 Dockerfile 을 훑어보고 구조가 바뀌었으면 suse.Dockerfile 을 손으로 다시 이식한다.

---

빌드

# 카탈로그가 쓰는 베이스 OS (기본값)
IMAGE=cnpg-postgresql BASE_OS=suse bash scripts/build/build-hardened-image.sh /tmp/out

# 레지스트리에 push 까지 (현재 실제 배포 이미지도 이 네임스페이스에 있다)
IMAGE=cnpg-postgresql BASE_OS=suse REGISTRY=docker.io/wbsong111 \
  bash scripts/build/build-hardened-image.sh /tmp/out

# 교차 검증을 함께 (사각지대 후보를 뽑는다. CI 에는 아직 연결되지 않았다)
CROSSREF=/tmp/ref/standard-trixie.json IMAGE=cnpg-postgresql BASE_OS=suse \
  bash scripts/build/build-hardened-image.sh /tmp/out

수행 순서: 빌드 → 기능 검증(verify.sh) → SBOM → 전 심각도 스캔 → 게이트 판정. 기능 검증을 통과하지 못하면 스캔으로 넘어가지 않는다. CVE 0건이어도 동작하지 않는 이미지는 카탈로그에 넣을 수 없다.

파일 구성

파일	역할
<base-os>.Dockerfile	빌드 정의
<base-os>.build.env	베이스·앱 버전·확장 목록. BUILD_ARGS 에 나열한 이름만 --build-arg 로 전달된다
verify.sh	기능 검증. 베이스 OS 공통 — CNPG 요구사항은 베이스와 무관하다

베이스 OS 가 늘어도 이 구조는 그대로다 — build-hardened-image.sh 는 BASE_OS 환경변수로 <base-os>.build.env 를 고른다.

태그에 빌드일을 넣는다

docker.io/wbsong111/cnpg-postgresql:18.4-bci15.7-hardened-20260729
                                     └ 앱 ─┘└ 베이스 ─┘└ 하드닝 ┘└ 빌드일 ┘

같은 앱 버전이라도 zypper update 결과가 시점마다 다르다. 롤링 태그를 피하고 자체 이미지에도 같은 실수를 하지 않는다(빌드일 포함 고정 태그).

이 태그는 security-catalog 프로젝트에서 이미 빌드·게이트 PASS·push 된 실제 이미지다. dip-catalog 는 이를 그대로 재사용한다 — 재빌드·재푸시 여부는 MEMORY.md 참고.

---

실측 (security-catalog, 2026-07-29 / trivy 0.72.0 기준)

	bci15.7-hardened-20260728
커버리지 자가진단	✅ ok
전 심각도 findings	0
실효 고유 C/H	0 / 0
게이트	PASS

채택 당시 비교 (후보 A/B/C, security-catalog 기준)

	업스트림 standard-trixie (A)	Ubuntu 24.04 자체빌드 (B, 제거됨)	SUSE BCI 15.7 (C, 채택)
패키지 수	148	147	182
trivy findings (전 심각도)	316	46	0
실효 고유 C/H	23	0	0
미조사 사각지대	0	18건	18건
서명·attestation	✅	❌	❌
배포 검증	—	✅ failover 2초	✅ failover 3초
gid	postgres	⚠️ tape	postgres

이 수치는 dip-catalog 에서 재측정한 것이 아니라 security-catalog 프로젝트에서 이관한 기록이다 — dip-catalog 자체 게이트로 재확인은 아직 하지 않았다(MEMORY.md 참고).