rancher 2.14.3
- custom-values 의 `preinstallHook: true` 제거. 2.10.1 에 있던
templates/preinstallHook/ (tls-ca secret 생성 Job)이 2.14.3 본문에는 없어
이 값이 아무 동작도 하지 않는다. dipup 은 설치 전 단계에서 직접 만든다
(pkg/kube/secret.go CreateRancherCASecret).
- privateCA: true 는 deployment 가 tls-ca secret 을 non-optional 로 마운트하게
하므로, 카탈로그 차트만으로 배포할 때 secret 이 없으면 파드가
ContainerCreating 에서 멈춘다. 해당 주의를 custom-values·CUSTOM-README 에 명시.
- BUILD-README 상단에 2.14.3 이 dipup tgz 전개본이라 이 문서의 차트 수정 절차가
적용되지 않았음을 명시하고, preinstallHook 단계를 무효 표시.
infisical-standalone 1.9.0
- custom-values 에 `ingress.nginx.enabled: false` 추가. 차트 기본값이 활성이라
스캐너(extract-helm-images.sh 가 custom-values 로 effective image 산출)가
dipup 이 배포하지 않는 k8s.gcr.io/ingress-nginx/controller:v1.1.0 ·
kube-webhook-certgen:v1.1.1 을 잡아 CVE 트리아지 잡음이 됐다.
dipup env/values/infisical-values.yaml 과 값을 맞춘다.
검증: 12/12 차트 helm template --kube-version 1.34.1 렌더 성공.
infisical effective image 가 dipup 배포분 3종으로 축소됨을 확인.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
dipup 이 go:embed 로 직접 보관·관리하던 Helm 차트를 카탈로그로 옮기는 첫 단계다.
두 저장소가 각자 CVE/SBOM 파이프라인을 운영하는 이중화를 해소하려면, 먼저 카탈로그가
dipup 과 같은 차트·같은 이미지를 보게 만들어야 한다.
배경: CVE 파이프라인 구성 이전에 두 곳에서 같은 차트를 유지하기 어려워 dipup 이 별도로
차트를 관리해 왔고, 그 결과 버전이 갈라졌다. 겹치는 10개 중 버전까지 일치하는 것은
postgresql-ha·dnsup 2개뿐이었다.
## 버전 갱신 (7개) — 신규 버전 디렉토리 추가, 구버전은 보존
| 차트 | 기존 | 신규 | appVersion |
|---|---|---|---|
| apisix | 2.14.0 | 2.16.0 | 3.16.0 → 3.17.0 |
| argo-cd | 7.7.0 | 7.8.11 | v2.13.0 → v2.14.5 |
| cert-manager | v1.16.1 | v1.21.0 | 동일 |
| gitea | 12.4.0 | 12.6.0 | 1.24.6 → 1.26.1 |
| harbor | 1.16.2 | 1.19.1 | 2.12.2 → 2.15.1 |
| kyverno | 3.4.1 | 3.8.2 | v1.14.1 → v1.18.2 |
| rancher | 2.10.1 | 2.14.3 | v2.10.1 → v2.14.3 |
차트 본문은 dipup 이 임베딩한 .tgz 를 그대로 전개했다(네트워크 pull 이 아니라 dipup 이
실제 배포하는 바이트와 동일함을 보장하기 위함). BUILD-README/CUSTOM-README/custom-values
3개 파일은 구버전에서 승계했다.
## 신규 추가 (5개)
infisical-standalone 1.9.0, longhorn 109.3.1+up1.11.2, longhorn-crd 109.3.1+up1.11.2,
metallb 0.16.1, secrets-operator v0.10.33.
longhorn/longhorn-crd 는 업스트림이 아니라 Rancher 패키징 차트(109.x 라인, Rancher 2.14
계열과 짝)다. BUILD-README 의 `helm repo add` 라인은 chart_version_detector 가 파싱하는
계약이라 실제 업스트림 repo 를 검증해 기재했고, 감지기로 현재/최신 버전이 정상 조회되는
것을 확인했다.
## custom-values — 버전과 결합된 이미지 핀 정리
카탈로그 스캐너가 dipup 의 effective image 를 보게 하려면 이미지 핀이 맞아야 한다.
- **kyverno: 승계본이 3.8.2 에서 깨져 재작성.** 3.4.1 은 정리 훅이
`registry: ~ / repository: bitnami/kubectl` 이라 bitnamilegacy 오버라이드가 맞았지만,
3.8.2 는 `registry: ghcr.io / repository: kyverno/readiness-checker` 로 바뀌었다.
그대로 옮기면 ghcr.io/bitnamilegacy/kubectl 이라는 없는 좌표가 된다. 해당 오버라이드를
제거하고, 3.8.2 에서 삭제된 policyReportsCleanup 키도 함께 뺐다. 남는 조치는 tag 고정뿐
(기본 tag 가 비어 latest 로 떨어짐 → v1.18.2 로 고정).
- apisix: 3.16.0-keycloak-authz → 3.17.0-keycloak-authz (차트 appVersion 과 함께 이동)
- gitea: image.tag 1.26.4 핀 추가 — 차트 기본 1.26.1 대비 CRITICAL 2→0, HIGH 44→12
- infisical: image.tag v0.162.7 핀 — 기본 v0.158.x 는 stale Debian base 로 OS 기인 CVE
다수(fixable CRITICAL 53→5, HIGH 491→55). redis/postgresql 은 bitnamilegacy 좌표로.
- longhorn: 실측 기반 리소스 튜닝(manager request, guaranteedInstanceManagerCPU,
systemManagedCSIComponentsResourceLimits). replica 수처럼 노드 수에 의존하는 값은
넣지 않았다 — 소비 측에서 주입한다.
## 검증
12개 차트 전부 `helm template --kube-version 1.34.1` 렌더 성공. 렌더 결과 이미지가
dipup 배포 이미지와 일치함을 확인(paasup/apisix:3.17.0-keycloak-authz,
gitea:1.26.4-rootless, readiness-checker:v1.18.2, infisical:v0.162.7).
## 범위에서 뺀 것
- **keycloak**: 카탈로그는 codecentric(app 17.0.1-legacy), dipup 은 bitnami(app 26.2.4)로
계보가 다르다. 이슈 #1(bitnami 대체 방안 검토)의 결론이 나온 뒤 처리한다.
- **rancher-monitoring(-crd)**: 14c05f1 에서 불필요 판단으로 제거된 차트이고
victoria-metrics 스택으로 대체 예정이라 추가하지 않는다.
- **dip-api/dip-console**: 자체 개발 차트로 각 앱 저장소가 출처다. 대조 결과 앱 저장소와
dipup 사본이 일치해 카탈로그가 개입할 이유가 없다.
- **postgresql-ha/dnsup**: 이미 버전이 일치해 작업 대상이 아니었다.
## 후속 과제
dnsup 은 카탈로그·dipup 사본(1.0.1)이 원본(dip-console-api helm/dnsup 1.0.0)보다 앞서
있다. 1.0.1 에만 있는 service.LoadBalancerIP·service.annotations 지원을 원본으로 백포트한
뒤, 카탈로그에서 dnsup 을 제거하는 것이 자체 개발 차트 출처 원칙에 맞다.
mlflow 도 ingressClassName 이 비어 있어 이 클러스터(apisix 전용)에서 Ingress 가
CLASS: <none> 으로 뜨고 어떤 컨트롤러도 처리하지 않았다 — ingress 경유 접근이
아예 불가능한 상태였다. path: / 도 exact 매치라 앱 리다이렉트 이후 404 가 난다.
전환 대상 4개 중 3개(airflow/superset/mlflow)가 같은 문제를 갖고 있었다.
실측 검증: /health OK, UI 200, experiments API 가 cnpg DB 에서 Default 실험을
반환 — ingress → 앱 → cnpg 전 경로 확인.
관련: #14
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
이슈 #9에서 결정된 CloudNativePG 채택을 카탈로그 앱에 확장 적용한다.
airflow/lakekeeper/mlflow/superset/flowise 5개 차트가 내장하던 bitnami
postgresql 서브차트를 끄고 앱 전용 cnpg-cluster 인스턴스를 외부 DB로 쓰도록
전환했다. 5개 모두 dev 클러스터 격리 네임스페이스에서 배포 테스트로 실측 검증했다.
gitea/keycloak/dnsup 는 서브차트가 아니라 공유 postgresql-ha 를 외부 참조하며
paasup/dipup 레포 관리 대상이라 제외했다 — 인수인계 문서만 추가했다.
배포 구조:
- ArgoCD ApplicationSet 으로 DB(syncWave 0) → 앱(syncWave 1) 순서를 보장한다.
기존 openmetadata/victoria-metrics 관례를 따랐다. cnpg-cluster 차트는 범용
상태로 유지하고 앱별 값은 manifests/applicationset/<app>/ 에 둔다.
검증 중 발견해 함께 고친 문제:
- lakekeeper: cnpg 의 -ro 는 replica 전용이라 instances:1 에서 엔드포인트가
0개다. 읽기 연결을 -r(전체 라운드로빈)로 교체했다.
- airflow/superset: ingressClassName 누락 + kong 애노테이션 잔존으로 이
클러스터(apisix 전용)에서 ingress 접근이 아예 불가능했다. apisix + regex
path 로 교체했다.
- 배포 테스트가 PV 만 지우고 Longhorn Volume CR 을 남겨 storageScheduled 가
누적됐다(orphan 112개 ~1TB 로 배포 차단). 두 스크립트의 정리 로직을 고쳤다.
재사용 구조화:
- .claude/skills/chart-to-cnpg/ 신규. 남은 4개 차트(langflow-ide, langfuse,
litellm, nemo)에 같은 절차를 재사용한다. flowise 에 실제 적용해 검증했다.
- 배포 테스트 공통 절차는 .claude/deploy-test-procedure.md, 환경 함정은
.claude/pitfalls.md 로 단일화하고 앱별 README 는 참조만 남겼다.
관련: #9, #14
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
불필요 판단으로 4개 차트 디렉토리를 통째로 삭제한다:
- manifests/helm/kong/2.46.0
- manifests/helm/unitycatalog/0.2.0 (define-chart-resources.md에도 "사용 여부
검토 필요"로 이미 표시돼 있었음)
- manifests/helm/rancher-monitoring/104.1.2+up57.0.3
- manifests/helm/rancher-monitoring-crd/104.1.2+up57.0.3
문서 정리:
- doc/define-chart-resources.md: 4개 차트의 리소스 프로파일 섹션 + 요약 테이블
행 삭제(섹션 번호는 재정렬하지 않음 — 범위 밖의 큰 변경이라 별도로 둠)
- doc/change-bitnami-image.md: kong·unity catalog 섹션 삭제(bitnami 이미지
치환 대상이 더 이상 없음)
doc/chart-restructure-plan.md는 건드리지 않았다 — 2026-01-19 charts/→manifests/
디렉토리 이전을 기록한 변경 이력이라, 그 시점에 실재했던 차트 목록을 지금 기준
으로 고치면 역사 기록이 왜곡된다.
manifests/applicationset 등 다른 배포 경로에서 이 4개 차트를 참조하는 곳이
없음을 확인했다.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
cloudnative-pg·cnpg-postgresql·etcd 를 REGISTRY=docker.io/paasup 로 재빌드해
verify.sh·게이트(커버리지 ok, 실효 C/H 0/0, PASS) 확인 후 push, docker manifest
inspect 로 레지스트리 존재를 재확인했다. 기존 참조(docker.io/wbsong111, 이전
security-catalog 빌드)는 dip-catalog 자체 파이프라인으로 검증된 적이 없었다.
카탈로그 values(custom-values.yaml/dip-values.yaml)를 patch-catalog-tag.py 로
새 태그로 교체하고 helm template·extract-helm-images.sh 로 렌더링 결과를
재확인했다. 로컬 docker 계정은 paasup push 권한이 확인됐으나 GitHub Actions
시크릿(DOCKERHUB_USER/TOKEN)의 권한은 별도 확인이 필요하다(MEMORY.md).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
Windows 노드 미사용 + Windows 이미지라 trivy 스캔 불가 → windowsExporter.enabled=false
로 SBOM/패키징 대상에서 제외.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
wbsong111