# 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`)이 이를 돕고, `scan-sbom.sh` 의 커버리지
자가진단(`CoverageProbe`)이 "0건"과 "측정 안 됨"을 구분한다(`doc/sbom-pipeline.md` 참고).
dip-catalog 로컬 빌드로 재확인(2026-08-03): 커버리지 `ok`, 실효 C/H 0/0, 게이트
PASS(`localhost/...` 태그, push 는 아직 안 함 — `MEMORY.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` 을 손으로 다시 이식한다.

---

## 빌드

```sh
# 카탈로그가 쓰는 베이스 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` 참고).