2 Commits

Author	SHA1	Message	Date
wbsong111	981d36daa4	차단 CVE 가 나오면 자체 빌드 이미지를 스스로 재빌드한다 + Dockerfile 작성 규칙 (#40) ... * 차단 CVE 가 나오면 자체 빌드 이미지를 스스로 재빌드한다 + Dockerfile 작성 규칙 두 가지다. (1) 이전 이미지에서 CVE 가 발견되면 재빌드가 자동으로 일어나게 한다. (2) Dockerfile 을 OS·언어 축으로 일관되게 쓰도록 규칙을 정한다. (1) 재빌드 자동화 — 트리거를 로컬 실측으로 고쳤다 ------------------------------------------------ 처음에는 트리거를 "핀이 뒤처졌는가" 로 잡았다. **배포 중인 이미지 8개를 실제로 스캔해 보니 그게 틀렸다** — 차단 CVE 가 있는 4개 중 핀 변경이 필요한 것은 하나도 없었고, 그 판정은 "0건" 을 냈다. 재빌드로 고쳐지는 경우가 셋이기 때문이다. 핀이 뒤처졌다 → 핀 올려서 빌드 핀은 맞는데 그 핀으로 아직 안 빌드됐다 → 그냥 빌드 ← 핀만 고친 PR 직후 상태 베이스 OS 패키지가 뒤처졌다 → 그냥 빌드 ← 재빌드하면 zypper 가 최신을 깐다 그래서 트리거는 **"수정 버전이 있는 차단 CVE 가 있는가"** 다. 핀 변경은 필요하면 함께 하는 부수 작업이고 트리거가 아니다. 수정 버전 없는 차단(affected·will_not_fix)은 재빌드해도 그대로이므로 no-fix 로 따로 보고해 사람이 다른 레버를 판단하게 한다. scripts/build/check-rebuild-needed.py 신규 카탈로그가 실제로 가리키는 이미지를 기준으로 잰다 — 재빌드해 보지 않고도 "지금 배포 중인 것이 규정을 벗어났는가" 를 답한다. catalog.env → 카탈로그 values 의 ref → 그 ref 의 스캔 리포트 ↕ build.env 의 핀 판정 규칙은 게이트와 같은 출처를 쓴다(max(벤더,NVD)·승인 예외·만료 예외 무효) — cve-gate.py 의 함수를 그대로 가져다 쓴다. 핀 산출은 suggest-go-upgrades.py 재사용. --list-refs 로 "무엇을 스캔해야 하나" 도 스크립트가 낸다 — ref 해석 규칙이 워크플로로 새면 두 곳이 어긋난다. suggest-go-upgrades.py 는 산출 로직이 main() 안에 있어 재사용할 수 없었다. collect_modules/ collect_stdlib/builder_candidates/effective_severity 로 빼고 main() 은 호출해 출력만 한다 — CLI 출력은 리팩터 전후 동일하다(실측 대조). build-image.yml 에 schedule(월요일 02:00 UTC)과 mode=drift 를 추가했다. 판정 → (핀이 뒤처졌으면) 브랜치 push → 빌드·verify.sh·게이트까지 자동이고 **레지스트리 push 와 카탈로그 반영은 하지 않는다.** 게시 여부 로직에서 catch-all 을 true → false 로 바꿨다 — 원래는 트리거를 추가하면 자동으로 push 가 켜지는 구조였고 schedule 을 넣는 순간 사고가 났다. 이제 push 는 workflow_dispatch + mode=image 에서만 켜진다. (2) Dockerfile 작성 규칙 — 실제 8개에서 추출했다 ---------------------------------------------- image-authoring.md 가 규칙 본문의 단일 출처이고 skill 은 "어느 절을 읽어야 하는가" 선택표만 갖는다(CLAUDE.md 의 "Skill 은 절차 본문을 복제하지 않는다"). 두 축은 독립이다 — 같은 bci-micro 최종 위에 Go 빌더도 Node 빌더도 온다. 축 1 최종 베이스 bci-base / bci-micro / scratch+micro rootfs — 셋뿐이다. 네 번째를 만들기 전에 왜 셋으로 안 되는지 먼저 적는다. micro·scratch 는 nonroot 계정을 직접 만들어야 한다(실측 형태 첨부). 축 2 빌더 Go(BUILDPLATFORM/TARGETARCH, ldflags 에 SOURCE_COMMIT) / Node(런타임은 OS 패키지) / JVM(재컴파일 없이 jar 만 OLD/NEW 쌍으로 교체 — OLD 를 받는 이유는 못 찾으면 실패시키기 위함) / C·Lua(정적 링크 금지 — SLE_BCI 에 static glibc 없음) "업스트림 런타임 계약은 보존한다" 절을 새로 넣었다(USER·ENTRYPOINT·파일 레이아웃). cloudnative-pg 가 멀티아치 심볼릭 링크를 부수 장치로 오판해 지웠다가 리컨실이 실패한 것이 근거다. 스캐너는 이걸 전혀 보지 못한다. 로컬 검증 — 판정만이 아니라 빌드까지 돌렸다 ----------------------------------------- 판정이 지목한 4건을 실제로 빌드해 전제를 확인했다. 문서에 단정만 해두고 넘어가지 않았다. 이미지 배포 중 재빌드 후 핀 변경 apisix-ingress-controller 차단 8 0/0 PASS · VERIFY-OK · cov=ok 없음 cloudnative-pg 차단 8 0/0 PASS · VERIFY-OK · cov=ok 없음 etcd 차단 8 0/0 PASS · VERIFY-OK · cov=ok 없음 cnpg-postgresql 차단 2 0/0 PASS · VERIFY-OK · cov=ok 없음 - cnpg-postgresql 이 "베이스 OS 패키지 갱신으로 해소" 사례다(perl·rpm-ndb). 핀을 하나도 안 바꾸고 재빌드만으로 0건이 됐다 — 검증 없이 단정했던 부분이라 이게 핵심 확인이다. - 빌드된 etcd 바이너리가 go1.26.6 + pinned commit 을 보고한다 — 핀이 실제로 반영됐다. - 4건 다 CoverageProbe=ok 이므로 0건이 "측정되지 않음" 이 아니다. - 빌드 후에도 git status images/ 가 깨끗하다 = 트리거를 핀 기준으로 뒀다면 4건 전부 놓쳤을 것이라는 확인. 그 외: 예외 적용(keycloak CVE-2025-59250 → 0건), --fail-on-drift rc=1, 워크플로 셸 재현 (GITHUB_OUTPUT 4개 JSON·fromJson OK·핀 변경 0 → 브랜치 미생성 → 기본 ref 로 빌드), push 정책 전 조합 확인. CI 에서 미검증인 것은 환경 특성뿐이다 — trivy 설치 스텝, GITHUB_STEP_SUMMARY 출력, matrix 팬아웃, contents:write 로 브랜치 push. 빌드 자체는 로컬과 같은 스크립트를 쓴다. Refs #35 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * self-build-image SKILL 의 자동 재빌드 절을 실행 계약만 남긴다 같은 커밋에서 image-authoring.md 와 SKILL 양쪽에 자동 재빌드 절차를 거의 동일하게 썼다. SKILL 이 "작성 규칙 본문은 image-authoring.md 가 단일 출처다 — 여기 복제하지 않는다" 고 두 번 선언한 파일에서 내가 그 규칙을 어겼다. SKILL 에는 실행 계약(수동 실행 명령 · 로컬 판정 명령 · push 안 한다는 사실)만 남기고 트리거 조건과 그 근거는 image-authoring.md 를 가리킨다. frontmatter 도 함께 고친다 — "7종" 에 argocd 가 빠져 있어 실제 images/ 8개와 어긋났다. description 은 Skill 로딩 판단에 쓰이는 텍스트이므로 "목록은 images/ 가 단일 출처" 라는 회피 조항으로 덮을 수 없다. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * 레포 분리 시 갈라지는 이음선을 코드와 문서에 명시한다 커스텀 이미지가 별도 레포로 분리될 예정인데, check-rebuild-needed.py 는 카탈로그(무엇을 배포 중인가)와 build.env(어떻게 만드는가)를 **양쪽 다** 읽는다. 분리 시 이 파일이 갈라진다. 절단면은 이미 함수 경계에 있다. 6개월 뒤에 "이 함수가 왜 카탈로그를 읽지" 를 다시 파지 않도록 어느 함수가 어느 쪽인지 docstring 에 적었다. A (카탈로그 레포) resolve_current_ref + blocking_cves → "차단됐는가" B (이미지 레포) pin_changes + apply_changes → "핀을 올려야 하는가" check_image 둘을 엮는 오케스트레이션 — 여기가 갈라진다 image-authoring.md 의 드리프트 절에도 같은 사실을 한 문단으로 적어 분리 작업 때 이 주석을 먼저 읽게 했다. 결합점 전체 목록은 경계 문서화 작업에서 표로 정리한다. 코드 동작은 바뀌지 않았다 — 주석과 문서만 추가했다. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-20 16:19:26 +09:00
wbsong111	33e91c0536	argocd: 자체 빌드 하드닝 이미지 추가, 게이트 차단 0건 ... 업스트림 quay.io/argoproj/argocd 의 차단 CVE 는 대부분 OS 패키지가 아니라 바이너리에 정적 링크된 Go 모듈이라, 상위 태그 교체(이미 최신)로도 베이스 OS 교체로도 잡히지 않는다. 부분 조치는 효과가 없었다 — 같은 stdlib·x/crypto 취약점이 다섯 바이너리(argocd·helm· kustomize·git-lfs·pebble)에 각각 들어있어 본체만 고치면 거의 줄지 않는다. 업스트림 Dockerfile 이 helm/kustomize/git-lfs 를 hack/install.sh 로 **미리 빌드된 릴리스 바이너리** 로 내려받기 때문에 그 바이너리의 Go 버전을 우리가 통제할 수도 없다. 그래서 넷 다 소스에서 다시 컴파일한다. - images/argocd/ 신규 (Go 4개 + C 2개 + Node UI — 기존 자체 빌드 중 가장 크다) - 최종 베이스 ubuntu → SUSE BCI(원칙 2). ubuntu 가 딸려오던 pebble 도 함께 사라진다 - tini·connect-proxy 는 SLE_BCI 에 없어 소스 빌드 — 기능을 빼지 않기 위해 - UI 는 업스트림과 동일하게 node 로 빌드(Go embed 라 생략 불가) - manifests/helm/argo-cd/10.4.0/custom-values.yaml 이 이 이미지를 가리킨다 global.image 하나로 argocd 바이너리를 쓰는 5개 컴포넌트가 공유한다 재사용 설계 — Dockerfile 에 버전을 박지 않는다 --------------------------------------------- 이 이미지는 앞으로도 CVE 조치를 반복해서 받는다. 모듈 목록·패키지 목록을 전부 값으로 빼서 다음 조치에서 바뀌는 것이 source.build.env 한 곳뿐이게 했다. 이전 방식이라면 모듈 하나 추가에 build.env·ARG 선언·go get 목록·BUILD_ARGS 네 곳을 고쳐야 했다. - scripts/build/suggest-go-upgrades.py 신규 — 스캔 리포트의 FixedVersion 에서 GO_MODULE_UPGRADES / GO_BUILDER_TAG 를 산출한다. 사람이 CVE 를 훑어 최대값을 고르지 않는다. 빌드 시점에 최신을 당기는 방식(go get -u)은 재현성을 버리므로 택하지 않았다 — 값은 제안만 하고 채택은 사람이 커밋한다. - images/argocd/go-mod-upgrade.sh 신규 — 목록 하나를 네 프로젝트에 재사용한다. go get 은 의존성에 없는 모듈도 go.mod 에 추가하므로 그래프에 있는 것만 골라 적용한다. 실측 함정 — verify.sh 에 반영했다 -------------------------------- 차트의 repo-server init 컨테이너가 `cp --update=none` 을 쓴다. 이 형식은 GNU coreutils 9.3+ 에서만 되는데, BCI 15.7 로 빌드한 이미지가 게이트도 verify.sh 도 통과하고 **배포 시점에** Init:CrashLoopBackOff 로 죽었다. BCI 16.0(coreutils 9.6)으로 올려 해소했고, verify.sh 가 이 명령과 copyutil 흐름을 직접 재현하도록 해서 다음엔 빌드 단계에서 걸린다. 16.0 의 패키지 가용성과 trivy 커버리지(CoverageProbe=ok, EOSL 아님)도 확인했다. 검증 ---- 게이트 PASS — 실효 CRITICAL/HIGH 0건, CoverageProbe ok 기능 VERIFY-OK (심볼릭 링크 9개 · 번들 도구 3종 · LFS 필터 · copyutil 흐름) 배포 docker.io/paasup 에 push 후 운영 argocd 교체 — 파드 8종 Running, admin 로그인, Application 2건 Synced/Healthy, repo-server 렌더링 확인 (서버가 go1.26.6 · helm v4.2.4 로 보고 — 우리 빌드가 맞다) 카탈로그 차단은 574 → 239 건이 됐고(7.7.0 삭제 · dex 비활성 · 이 커밋), 남은 239 건은 전부 동결된 7.8.11 몫이다. 운영에 쓰는 10.4.0 은 0 건이다. 경과·미결은 MEMORY.md. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 15:04:05 +09:00