Files

T

wbsong111 6878b61efa 자체 빌드 이미지 3종(cloudnative-pg/cnpg-postgresql/etcd) + 대응 헬름 차트 도입

security-catalog 프로젝트에서 첫 실사용 자체 빌드 이미지 3종을 포팅한다 — 전부
상위 태그·베이스 OS 교체로 해소 안 되는 CVE(Go 모듈 정적 링크 또는 미수정 CRITICAL/
HIGH)를 자체 빌드(소스 컴파일 또는 SUSE BCI 재설치)로 대응한다:

- images/cloudnative-pg: CNPG operator, release-1.30 소스 컴파일 + bci-micro
- images/cnpg-postgresql: PostgreSQL 18.4, bci-base + zypper 재설치
- images/etcd: etcd v3.7.1, 소스 컴파일(x/text 강제 업그레이드) + bci-micro

함께 추가:
- manifests/helm/{cloudnative-pg,cnpg-cluster,etcd} — 위 이미지를 참조하는 카탈로그 차트
- scripts/deploy-test/*.sh, .claude/deploy-test-procedure.md — CVE 0건과 별개로
  "실제로 뜨는가"를 검증하는 배포 스모크 테스트
- .claude/pitfalls.md — 자체 빌드/배포 테스트 중 실측한 함정 모음

검토 중 발견해 반영한 수정:
- cloudnative-pg 차트의 image 블록을 etcd와 동일한 registry/repository/tag 3필드+
  따옴표 포맷으로 통일 — 기존 포맷(repository에 registry+repo 결합, 따옴표 없음)은
  patch-catalog-tag.py 의 split 패처가 tag만 갱신하고 repository는 그대로 남기는
  조용한 부분 치환을 일으켜, 향후 레지스트리 마이그레이션 시 깨진 참조를 만들 수 있었다
- cnpg-cluster 차트의 SLES 커버리지 코멘트를 최신 실측(trivy가 SLES 15.7을 정상
  커버함, 2026-07-29 재측정)에 맞게 정정 — 폐기된 "측정 불가/OVAL 우회 필요" 결론이
  남아있었다
- CLAUDE.md/MEMORY.md 의 "images/ 디렉토리 없음" 서술을 갱신하고, 레지스트리
  마이그레이션(docker.io/wbsong111 → docker.io/paasup)·decisions/analysis 문서 이관·
  리소스 프로파일 추가를 다음 작업으로 기록

이 3개 이미지는 아직 dip-catalog 자체 CI(build-image.yml)로 빌드·게이트·push 를
실행해본 적이 없다 — 현재 참조 태그는 security-catalog 쪽에서 이미 검증된 것이다.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-08-03 12:03:37 +09:00

5.8 KiB

Raw Blame History

etcd — 자체 빌드

etcd 서버/etcdctl/etcdutl 바이너리를 업스트림 소스에서 직접 컴파일한다. manifests/helm/etcd/1.1.12/custom-values.yaml 의 image.repository/image.tag 가 이 산출물을 가리킨다.

security-catalog 프로젝트에서 포팅했다. 목표 정의·CVE 조사 실측·이미지 채택 결정 근거(각각 doc/cve-zero-pipeline.md, doc/analysis/etcd-cve.md, doc/decisions/0007-etcd-image-self-build.md)는 security-catalog 프로젝트에 있고 dip-catalog 에는 아직 이관되지 않았다 — 신규 자체 빌드 이미지 추가 절차 전반은 .claude/image-authoring.md 참고.

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

왜 자체 빌드하나 — 그리고 왜 `cloudnative-pg` 와 같은 방법인가

업스트림 quay.io/coreos/etcd:v3.7.1 은 실효 HIGH 1건(CVE-2026-56852, golang.org/x/text — 깨진 UTF-8 입력에 대한 norm.Iter 무한루프 DoS)으로 차단된다. 상위 태그가 없다(2026-07-31 확인, 최신 릴리스가 여전히 v3.7.1이고 release-3.7 브랜치도 아직 이 CVE 를 백포트하지 않았다). 업스트림 배포 이미지 베이스가 gcr.io/distroless/static-debian12(OS 패키지 사실상 0개)라 베이스 OS 를 바꾸는 것만 으로는 고쳐지지 않는다 — CVE 는 바이너리에 정적 링크된 Go 모듈 버전이 원인이다. 자체 빌드(소스 컴파일)만 유효한 대응이다.

이는 cloudnative-pg 오퍼레이터 자체 빌드와 완전히 같은 유형의 문제(같은 CVE-2026-56852)이고 대응도 같다 — 오케스트레이션은 동일한 scripts/build/build-hardened-image.sh 하나를 공유한다.

소스·버전 관리

항목	값
소스	`https://github.com/etcd-io/etcd.git`
pinned commit	`source.build.env` 의 `SOURCE_COMMIT` — `v3.7.1` 태그가 가리키는 실제 커밋
빌더	공식 `golang` 이미지 (`source.build.env` 의 `GO_BUILDER_TAG`, go.mod 요구 버전과 일치)
최종 베이스	`registry.suse.com/bci/bci-micro:15.7` — security-catalog 는 SUSE BCI 하나만 쓰기로 결정했다(ADR 미이관); 업스트림의 distroless 대신 여기 적용

빌더 스테이지(Go 컴파일)는 공식 golang 이미지를 그대로 쓴다 — 최종 이미지에 남는 것이 아니라 컴파일 산출물만 최종 스테이지로 넘어오므로 스캔·정책 대상이 아니다.

업스트림과 다른 부분은 딱 하나다 — golang.org/x/text 를 워크스페이스 전역 go.work replace 한 줄로 0.39.0 이상으로 강제 업그레이드한다(각 서브모듈의 go.mod 를 개별로 고치지 않는다). 그 외 빌드 절차(server/etcdutl/etcdctl 세 바이너리를 각각 컴파일, CGO_ENABLED=0 정적 링크)는 업스트림 scripts/build_lib.sh 의 etcd_build() 를 그대로 재현한다.

SOURCE_COMMIT 은 자동 추적하지 않는다. cloudnative-pg 와 동일하게 사람이 업스트림 release-3.7 브랜치(또는 그다음 패치 릴리스가 나오면 그 태그)를 보고 source.build.env 를 고쳐 PR 을 여는 것 자체가 갱신 트리거다.

권장 점검 주기: 카탈로그 게이트가 이 이미지의 차단 CVE 를 다시 보고할 때, 또는 업스트림이 v3.7.2(혹은 그 이상, x/text 백포트 포함)를 릴리스했을 때 — 릴리스가 나오면 그쪽으로 갈아타는 것(대응 우선순위 a)이 이 자체 빌드를 유지하는 것보다 항상 우선이다.

빌드

# 로컬 빌드 (push 없음)
IMAGE=etcd BASE_OS=source bash scripts/build/build-hardened-image.sh /tmp/out

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

수행 순서: 빌드 → 기능 검증(verify.sh) → SBOM → 전 심각도 스캔 → 게이트 판정. verify.sh 는 etcd/etcdctl/etcdutl 이 PATH 에 있는지, etcd --version 출력에 pinned commit 이 실제로 반영됐는지(ldflags 주입 확인), 단일 노드로 기동해 etcdctl put/get 왕복이 실제로 동작하는지를 확인한다 — 다중 노드 쿼럼·TLS 등은 이 스모크 테스트 범위 밖이며, dev 클러스터 배포 테스트(.claude/deploy-test-procedure.md, scripts/deploy-test/deploy-test-etcd.sh)가 담당한다.

파일 구성

파일	역할
`source.Dockerfile`	빌드 정의 — 소스 컴파일(builder 스테이지) + SUSE BCI(`bci-micro`) 패키징(final 스테이지)
`source.build.env`	pinned commit·버전·빌더 이미지 태그. `BUILD_ARGS` 에 나열한 이름만 `--build-arg` 로 전달된다
`verify.sh`	기능 검증. 호스트에서 bash 로 실행되며 `docker run --entrypoint sh` 로 게스트 셸 스크립트를 주입한다(`bci-micro` 는 bash·coreutils 가 있다 — `cnpg-postgresql/verify.sh` 와 같은 패턴, `cloudnative-pg` 의 셸 없는 distroless 와는 다르다)

베이스 변종이 하나뿐이라 파일명이 source.* 로 고정돼 있다.

5.8 KiB Raw Blame History

etcd — 자체 빌드

왜 자체 빌드하나 — 그리고 왜 cloudnative-pg 와 같은 방법인가

소스·버전 관리

빌드

파일 구성

태그

5.8 KiB

Raw Blame History

왜 자체 빌드하나 — 그리고 왜 `cloudnative-pg` 와 같은 방법인가