nemo 의 NGC API 키와, airflow git-sync · gitea · keycloakx 가 공유하던 암호가
평문으로 커밋돼 있었다. airflow 쪽은 같은 값을 base64 로 감싼 것이라 5개 파일을
함께 교체했다.
4개 차트 helm template 렌더 확인. 히스토리와 GitHub PR ref 에는 남으므로 키
로테이션이 별도로 필요하다.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
#29 는 webserverSecretKey 에 placeholder 를 두고 콘솔이 배포 시점에 난수로 치환하게 했다.
신규 배포는 고정됐지만 재배포 경로에서 되살아났다 — 콘솔의 재배포 분기가 이미 치환된
values 가 아니라 placeholder 가 남아 있는 default_values_yaml 을 다시 parse 해서 매번 새
난수를 만든다. 실측에서 재배포 3회에 webserver ReplicaSet 이 3개 생겼고, airflow-config ·
metadata-secret · webserver-config 등 다른 체크섬은 전부 같은데
checksum/webserver-secret-key 하나만 달랐다.
fernet key(#38, PR #45)가 이미 쓰는 "이름을 넘긴다" 방식으로 바꾼다. 이쪽이 값을 고정하는
것보다 강하다 — webserverSecretKeySecretName 이 설정되면 Secret 템플릿이 `if not` 가드로
비고 checksum/ 애노테이션이 해싱하는 대상이 상수가 된다. Deployment spec 이 애초에 키 값에
의존하지 않게 되므로 앞으로 어떤 이유로 키가 바뀌어도 롤링이 발생하지 않는다. 키가 tenant
레포(git)에 평문으로 남지도 않는다.
값 이름은 webserverSecretKeyName 이 아니라 webserverSecretKeySecretName 이다
(values.yaml:500). 차트가 읽는 Secret 의 키 이름은 webserver-secret-key 로 하드코딩돼
있다(_helpers.yaml:99).
CUSTOM-README 5절은 두 비밀값을 같은 방식으로 설명하도록 고치고, helm 직접 배포 절차에
webserver Secret 생성을 추가했다. 마이그레이션 시 ArgoCD prune 주의사항도 적었다 —
차트가 만들던 Secret 은 tracking-id 가 붙은 추적 대상이라 콘솔이 인수할 때 그 애노테이션을
벗겨내야 한다.
세 파일 모두 service-catalog(ac5ae54, 배포 반영 완료)와 바이트 동일하다.
Closes#46
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
차트가 fernet key Secret 을 직접 만들면 helm.sh/hook: pre-install +
hook-delete-policy: before-hook-creation 이 붙는다. ArgoCD 는 훅을 "삭제 후 재생성" 하는데,
변경이 없는 sync 에서는 삭제 직후 operation 이 종료되어 재생성되지 않는다. 컨트롤러 로그로
확인했다.
변경 있는 sync waiting for deletion ... -> serverside-applied -> Succeeded 'all tasks run'
no-op sync waiting for deletion ... -> Succeeded (같은 초) 'no more tasks'
파드는 이미 주입된 env 로 계속 돌아 증상이 즉시 드러나지 않지만, 재시작하는 순간
CreateContainerConfigError 로 기동하지 못한다. refresh·selfHeal 로 흔히 발생하는 상황이다.
fernetKeySecretName 을 주면 차트가 Secret 을 아예 만들지 않으므로
(templates/secrets/fernetkey-secret.yaml:23) 훅 자체가 사라지고, 모든 워크로드가 그 이름을
secretKeyRef 로 참조한다(templates/_helpers.yaml:395-397).
$FERNET_KEY_SECRET 은 placeholder 다. dip-console-api 가 <릴리스명>-fernet-key Secret 을
만들고(없을 때만) 이 자리를 그 이름으로 치환한다. 콘솔이 만든 Secret 은 ArgoCD 추적 대상이
아니라 sync 의 영향을 받지 않는다.
값이 아니라 이름을 넘기는 이유가 하나 더 있다 — fernet key 는 메타DB 의
Connection·Variable 암호화에 쓰이므로 tenant 레포(git)에 평문으로 남기지 않는다.
업스트림도 can only be set during install, not upgrade 라고 못박고 있어, 이미 배포된
테넌트는 재배포 시 현재 Secret 을 그대로 인수한다.
CUSTOM-README 5절은 이 문서의 성격(배포 방법 · custom-values.yaml 키 설명)에 맞게 키
테이블과 배포 절차 중심으로 다시 썼다(69줄 -> 48줄). 상세 근거는 이슈로 넘긴다.
redis 훅 Secret 2종은 CeleryExecutor 전환 예정이 없어 조치하지 않는다. 참조 워크로드가
0개인 것을 클러스터에서 확인했다. 전환 시 처리 방법만 문서에 남긴다.
검증
service-catalog 에 선반영해 테스트 클러스터에서 확인했다. 재배포 후 sync 를 걸었을 때 훅인
redis Secret 2종은 또 삭제됐고 콘솔이 관리하는 fernet Secret 만 살아남았다(resourceVersion
미동, 값 동일). 이 레포 기준으로도 helm template 2회 렌더에서 차트가 fernet Secret 을 만들지
않고 webserver 체크섬이 동일함을 확인했다.
관련: paasup/dip-catalog#38, paasup/dip-console-api#100
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`demo01-air` 에서 webserver 가 반복 롤링되고 migrations job 이 5분 주기로 재실행되던
것을 추적한 결과, 원인이 서로 다른 두 개였고 둘 다 카탈로그 기본값에서 비롯됐다 —
모든 airflow 테넌트가 해당된다.
원인 1 — webserverSecretKey 가 렌더할 때마다 바뀐다
값을 주지 않으면 차트가 템플릿에서 직접 난수를 만들고(`randAlphaNum 32`), 그 Secret 이
webserver·worker Deployment 의 `checksum/webserver-secret-key` 애노테이션에 물려 있어
렌더할 때마다 Deployment spec 이 바뀐다. 캐시된 매니페스트를 쓰는 reconcile 로는
일어나지 않지만 일반 refresh 만으로도 일어난다(실측).
차트 안에서는 못 고친다. `lookup` 재사용은 ArgoCD repo-server 가 클러스터 접근 없이
클라이언트 렌더를 하므로 항상 빈 값이다(클러스터에 Secret 이 실재하는데도 빈 값인 것을
확인). 릴리스명·네임스페이스 기반 결정적 파생은 렌더는 안정되지만 파생 입력이 전부 공개
정보라 세션 서명 키를 예측할 수 있어 부적합하다. 값이 차트 바깥에서 와야 한다.
그래서 `$WEBSERVER_SECRET_KEY` placeholder 를 두고, 배포 시점에 dip-console-api 가
난수로 치환한다(`catalogs/catalogtype/catalog_airflow.go` 의 `DeployPreInstall`).
치환된 values 가 tenant 레포에 저장되므로 이후 렌더는 그 고정값을 쓴다. 공용
`catalog_type_base.go` 가 아니라 airflow 전용 훅에 둔다.
원인 2 — migrations job 이 TTL 삭제 ↔ selfHeal 재생성 루프에 빠진다
`useHelmHooks: false`(업스트림이 ArgoCD 환경에 권고) 로 Job 이 ArgoCD 추적 리소스가
됐는데 차트 기본값 `ttlSecondsAfterFinished: 300` 이 그대로 남아 있었다. 완료 300초 뒤
TTL 컨트롤러가 Job 을 지우면 ArgoCD 가 OutOfSync 로 보고 selfHeal 이 다시 만든다.
템플릿에서 TTL 은 `useHelmHooks` 와 무관하게 항상 렌더되고 `kindIs "invalid"` 일 때만
빠지므로, `~` 로 꺼서 필드 자체를 없앤다. 대신 완료된 Job 객체가 남는다.
반영 위치가 2곳이다 — helm 카탈로그와 applicationset(`---` 뒤 두 번째 문서) 양쪽.
한쪽만 고치면 배포 경로에 따라 증상이 남는다.
주의 — dip-console-api 와 짝이다. 한쪽만 머지되면 placeholder 문자열이 그대로 키가
되거나(카탈로그만) 아무 일도 일어나지 않는다(console 만). 이미 배포된 테넌트는
재배포해야 적용된다.
fernet key 는 같은 구조지만 체크섬에 물려 있지 않아 증상·마이그레이션 경로가 다르다 —
별건(#38)으로 둔다.
Refs #29
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
위 4개 커밋은 build-image.yml 이 자동 생성한 것이고, cnpg-postgresql 은 1.0.0 만 갱신됐다.
1.1.0 도 같은 이미지를 가리키는데 낡은 태그(20260803)로 남아 있었다.
원인은 매핑이다. images/cnpg-postgresql/catalog.env 의 CHART_DIRS 가 1.0.0 하나만 선언해
워크플로가 1.1.0 을 볼 방법이 없었다. 카탈로그는 여러 버전을 동시에 보관하는 "버전 보관소"
이므로 이미지 하나가 여러 버전 디렉토리에 걸리는 것이 정상이다 — 매핑이 그것을 표현해야 한다.
CHART_DIRS="manifests/helm/cnpg-cluster/1.0.0"
→ CHART_DIRS="manifests/helm/cnpg-cluster/1.0.0 manifests/helm/cnpg-cluster/1.1.0"
다른 세 이미지는 전수 확인 결과 CHART_DIRS 가 참조를 전부 덮는다(etcd 1.1.12 ·
cloudnative-pg 0.29.0 · apisix 2.16.0). cnpg-postgresql 만 누락이었다.
이 누락은 조용히 지나간다는 점이 문제다 — patch-catalog-tag.py 는 "예상 패턴을 못 찾으면
실패" 하지만, 애초에 대상 목록에 없는 파일은 검사하지 않는다. 매핑이 불완전하면 게이트만
계속 그 이미지를 차단으로 잡고 이유를 알기 어렵다.
Refs #35
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
images/·manifests/helm/·.claude/ 의 20개 파일이 doc/decisions·doc/analysis 등 **이 레포에
존재한 적 없는 경로 15종을 48곳에서** 인용하고 있었다. security-catalog 에서 포팅할 때
따라온 것인데, 그 레포는 개인 레포(github.com/wbsong111/security-catalog)라 팀 구성원은
접근조차 못 한다 — "security-catalog 에 있으나 이관되지 않았다" 는 안내가 아무 역할을
하지 못했다.
원문을 통째로 복사하지 않았다
----------------------------
원본 문서들이 서로를 근거로 인용한다. decisions/0001 하나만 봐도 analysis/cnpg-image-baseline.md
· analysis/vendor-unassessed-data-sources.md 처럼 **인용 목록에 없던 또 다른 미이관 문서**를
가리킨다. 복사는 문제를 옮기는 것이지 없애는 게 아니다.
그리고 대부분은 애초에 dip-catalog 가 더 나은 것을 갖고 있다. 7곳에서 인용되던
analysis/sles-oval-measurement.md 는 원문 스스로 "이 문서는 결정하지 않는다. 재측정하면
갱신된다" 고 밝히는 스냅샷인데, dip-catalog 는 같은 측정을 CoverageProbe 로 매 스캔마다
자동으로 한다. 문서를 복사하는 것보다 게이트를 가리키는 것이 정확하다.
그래서 성격별로 나눴다
---------------------
재측정으로 복원 안 되는 것 → doc/decisions/ 에 자립적 ADR 로 다시 씀 (4건)
이미 단일 출처가 있는 것 → 그쪽으로 인용 교체 (11종 경로)
ADR 4건은 security-catalog 0001·0005·0006·0007 이 원본이고, 결론과 근거만 추려
dip-catalog 맥락으로 새로 썼다 — **레포 밖을 가리키는 링크가 0이다.** 번호는 이 레포에서
0001~0004 로 다시 붙였고 원본 대응은 각 문서와 README 에 적었다. 왜 안 가져온 것은 안
가져왔는지도 README 표에 남겼다.
인용 교체는 카테고리별로:
analysis/*-cve.md, cnpg-image-vuln-comparison.md → 해당 ADR · images/<image>/README.md
analysis/sles-oval-measurement.md → 게이트 CoverageProbe (doc/sbom-pipeline.md)
cve-zero-pipeline.md, architecture/build-pipeline.md → doc/sbom-pipeline.md
image-selection.md → .claude/image-authoring.md
charts/*/deploy-test.md → scripts/deploy-test/*.sh + 절차 문서
찾은 오류 2건
-------------
- images/cloudnative-pg/source.build.env 가 인용한 decisions/0004-cloudnative-pg-operator-self-build.md
는 **번호 오기**다. 원본 0004 는 postgresql-chart-selection 이고 이 결정은 0005 다.
- cnpg-cluster values.yaml·templates/database.yaml 이 인용한 doc/deploy-test-cnpg.md 는
**원본 레포에도 없다.** CREATE EXTENSION 함정 설명은 주석 자체에 이미 있어 인용만 뺐다.
검증
----
우리 파일의 깨진 doc/ 인용 0건 (전수 스캔)
새 문서·수정 문서의 로컬 링크 전부 실재 확인
helm template cnpg-cluster · etcd · cloudnative-pg 정상 렌더
남은 doc/health-checking.md(144곳)·doc/integration/*(2곳)은 업스트림 CRD·차트 안의 문자열로
우리가 쓴 인용이 아니다 — 건드리지 않았다.
Closes#33
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
업스트림 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>
CVE 게이트 실측에서 ghcr.io/dexidp/dex:v2.45.1 이 혼자 차단 57 건을 만들고 있었다.
argo-cd 10.4.0 전체 98 건의 58% 다. 그런데 이 dex 는 인증 경로에 전혀 관여하지
않는 상태였다.
차트 기본값 dex.enabled = true
운영 argocd-cm oidc.config 있음(Keycloak 직접) / dex.config 없음
dipup tpl 항상 configs.cm.oidc.config — dex 참조 0건
ArgoCD 는 oidc.config 가 있으면 dex 를 우회하고 dex.config 를 쓸 때만 dex 가
관여한다. 즉 쓰이지도 않는 파드가 떠서 차단 CVE 의 절반 이상을 만들고 있었다.
대응 레버를 순서대로 검토한 결과 이 방법이 먼저였다.
태그 교체 소진 — dex v2.45.1(2026-03-03) · argocd v3.5.1(2026-08-12) 모두 최신.
번들 도구도 git-lfs 3.7.1 · kustomize 5.8.1 로 이미 최신이고,
낡은 Go 는 각 업스트림 프로젝트의 선택이라 버전으로 해결되지 않는다.
베이스 OS 무의미 — 차단 98 건 중 9 건(9%)만 OS 패키지다. 89 건이 Go 모듈이라
바이너리에 컴파일돼 들어가 있어 베이스를 바꿔도 남는다.
미사용 제거 ← 이것. 한 줄로 57 건(58%).
자체 빌드 남은 41 건 대상. 별건으로 검토한다.
검증:
게이트 재실행 차단 337 → 280 건 (10.4.0 몫 98 → 41)
배포 테스트 PASS — 워크로드 7종 → 6종, dex-server 사라짐, /api/version v3.5.1
dex 기반 SSO 로 전환하려면 dex.enabled 를 true 로 되돌리고 configs.cm.dex.config 를
채운다. 그때 dex 이미지의 CVE 가 다시 잡히므로 대응 계획이 함께 필요하다 —
CUSTOM-README 에 근거와 함께 적어뒀다.
7.8.11(구버전)의 dex 는 건드리지 않았다. released 된 버전이라 동결한다.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
카탈로그가 한 차트의 여러 버전을 들고 있어서, 게이트 요약표에 버전 정렬이 없으면
최신 버전과 구버전이 위험도 순으로 섞여 "지금 쓸 버전이 어느 정도인가" 를 한눈에
볼 수 없었다. 실측 사례 — argo-cd 10.4.0 이 구버전 7.8.11 사이에 끼어 표시됐다.
변경 전 (chart asc → 실효 C/H desc)
argo-cd@7.8.11 argocd:v2.14.5 14/101
argo-cd@7.8.11 redis:7.4.2 5/60
argo-cd@10.4.0 dex:v2.45.1 5/52 ← 최신이 구버전 사이에
argo-cd@7.8.11 dex:v2.42.0 4/55
argo-cd@10.4.0 argocd:v3.5.1 1/40
변경 후 (chart asc → 버전 desc → 실효 C/H desc)
argo-cd@10.4.0 dex:v2.45.1 5/52
argo-cd@10.4.0 argocd:v3.5.1 1/40
argo-cd@10.4.0 redis:8.6.4 0/0
argo-cd@7.8.11 argocd:v2.14.5 14/101
argo-cd@7.8.11 redis:7.4.2 5/60
argo-cd@7.8.11 dex:v2.42.0 4/55
- scripts/pipeline/cve-gate.py
- version_sort_key() 추가. 문자열 비교로는 "10.4.0" < "7.8.11" 이 되어 최신이
아래로 내려간다. 숫자 구간을 정수로 파싱한다.
프리릴리스는 코어와 분리해 다룬다 — 단순히 구간을 이어붙이면 리스트가 긴 쪽이
커져 "1.2.0-rc1" 이 "1.2.0" 보다 최신으로 정렬된다(단위 테스트로 실측).
semver 규칙대로 프리릴리스 없는 정식 릴리스를 더 크게 본다.
- 정렬은 안정 정렬을 3번 겹쳐 만든다. 버전만 내림차순이라 reverse=True 가
필요해 한 번에 튜플 하나로 묶을 수 없다.
- manifests/helm/argo-cd/7.7.0 제거
게이트 차단 574건 중 237건이 이 버전의 이미지 3개였다
(argocd:v2.13.0 117 / dex:v2.41.1 61 / redis:7.2.4-alpine 59 — 뒤 둘은 EOSL).
제거 후 차단 337건.
doc/catalog-stack-classification.md 의 버전 목록도 갱신했다(10.4.0 이 빠져 있어
이미 stale 이었다). doc/chart-restructure-plan.md 는 과거 이관 기록이라 두었다.
로컬 파이프라인으로 검증했다(extract → generate → scan → gate, argo-cd 범위).
이미지 6개 / SBOM 6개 성공 / 커버리지 전부 ok.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
k8s 1.33 에서 Deployment/ReplicaSet 에 추가된 .status.terminatingReplicas 를
ArgoCD v2.14.5(k8s 라이브러리 0.31/0.32)가 몰라, 클러스터가 1.33 이상이면
ServerSideApply=true 인 Application 이 전부 아래 오류로 죽는다.
ComparisonError: failed to calculate diff: error calculating structured
merge diff: .status.terminatingReplicas: field not declared in schema
v3.5.1 은 k8s 라이브러리 0.36.1 을 써서 해소된다. dev 클러스터(1.35.7+rke2r1)
에서 실제 발생·해소를 확인했다.
- manifests/helm/argo-cd/10.4.0/ 추가 (chart_updater 로 생성)
- custom-values.yaml 을 실제 배포 기준(dipup argo-cd-values.yaml.tpl)에 맞춤:
kong → apisix, server.extraArgs(--insecure), configs.cm/rbac 추가
- configs.params.controller.resource.health.persist=true 지정 —
ArgoCD v3.0 부터 리소스 health 를 CR 에 저장하지 않는 것이 기본값인데,
dip-console-api 가 .status.resources[].health 를 읽는다
- CUSTOM-README.md 는 현재 차트 기준 배포 가이드로 재작성.
승계된 cert-manager 예시가 10.4.0 에 없는 구버전 스키마(hosts/tls 리스트)라
Ingress 가 생성되지 않는 상태였던 것도 함께 수정
- breaking_change_check: breaking=false (제거 26건이 전부 미사용 key)
- scripts/deploy-test/deploy-test-argo-cd.sh 신규
같은 클러스터에 두 번째 argo-cd 를 띄우려면 crds.install=false 가 필수다 —
CRD 3종이 클러스터 전역이고 운영 릴리스가 소유해 Helm 이 ownership 충돌로
거부한다. Ingress 도 항상 끈다(운영과 host 충돌).
검증: 워크로드 롤아웃 / health.persist / api 버전 / admin 로그인
- argo-cd/7.8.11/BUILD-README.md 에 `helm repo add argo ...` 추가
chart_version_detector 가 이 한 줄을 정규식으로 뽑아 업스트림 레포를 정하는데,
argo-cd 에는 없어서 신규 버전 자동 감지가 조용히 실패하고 있었다
(repo: null → latest_version: null). CLAUDE.md 의 "변경 금지" 규정도
실제 파싱 계약에 맞게 정정했다.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-ingress-unauth 는 kubectl get ingress 목록에서 "인증 없는 입구"를
그대로 광고한다. 리소스가 무엇인지가 아니라 무엇이 없는지로 이름을
지은 것이기도 해서, 경로가 /static 외로 늘어나면 이름이 뜻을 잃는다.
파일명(webserver-ingress-static.yaml)과 일치시키고 용도를 그대로
드러내는 -ingress-static 으로 바꾼다. 값 키 dip.unauthenticatedPaths
는 values 파일 안에만 있고 의도를 정확히 서술하므로 그대로 둔다.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
세션이 없는 상태로 접속하면 Airflow UI 한 페이지가 /static 자원을 수십 개
동시에 요청하고, 각 요청이 저마다 APISIX openid-connect 로그인 플로우를
시작한다. 세션은 state를 하나만 보관하므로 콜백이 동시에 돌아오면 마지막
하나를 뺀 전부가 state 검증에 실패해 500이 난다.
templates/webserver/webserver-ingress-static.yaml 은 업스트림 Apache Airflow
차트에 없는 PaaSup 추가 템플릿이다. dip.unauthenticatedPaths 가 있을 때만
애노테이션 없는 Ingress를 하나 더 렌더해 해당 경로를 인증 없이 통과시킨다.
애노테이션을 전부 비우는 것은 의도된 것으로, plugin-config-name 을 빼는 게
목적이고 cert-manager.io/* 까지 빼는 이유는 웹 Ingress와 같은 TLS Secret 을
두고 Certificate 를 중복 생성하지 않게 하기 위해서다.
값을 ingress.web 아래가 아니라 dip 아래에 두는 이유는 values.schema.json 의
ingress.web 이 additionalProperties: false 라 그 아래 새 키를 넣으면 스키마
검증에서 배포가 실패하기 때문이다. qdrant·litellm 의 dip.mainPath 와 같은
자리를 쓴다.
webserver-ingress.yaml 과 동일한 조건으로 렌더하므로 Airflow 3.0
(webserver → api-server) 전환 시 함께 재작업이 필요하다. 업스트림 파일은
수정하지 않았고 fork 델타는 신규 템플릿 1개뿐이다.
이슈 #24 는 dip-console 이 차트 밖에서 생성하는 방안(B안)을 권고했으나,
실제로 증상이 재현되는 서비스가 airflow 하나로 좁혀져 차트 템플릿(A안)으로
갔다. dip-console 로 옮길 때는 dip.unauthenticatedPaths 를 비우면 된다.
redirect_uri 고정은 여전히 dip-console 몫으로 남는다.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
flowise/6.0.0 의 dip-values.yaml + dip-questions.yaml 스키마를 airflow 에 적용했다.
doc1 은 cnpg-cluster(airflow-db), doc2 는 airflow 본체다.
dip-values.yaml
- bootstrap.initdb 의 database/owner 는 airflow-db-values.yaml 과 맞춘 airflow.
- databases[] 도 airflow/airflow. 차트 기본값인 appdb/appuser 를 쓰면 appuser
롤이 생성되지 않아 Database CR reconcile 이 실패한다.
- bootstrap.initdb 에는 ensure/reclaimPolicy 를 넣지 않았다. cnpg-cluster 의
cluster.yaml 이 읽지 않는 databases[] 전용 키다.
- postgresql.enabled: false. 내장 bitnami 대신 syncWave 0 의 cnpg 를 쓴다.
- metadataConnection.host 는 "{{ .Name }}-airflow-db-rw". dip 배포는 cnpg
릴리스명에 테넌트 접두사를 붙여 나간다(관측: instance=demo01-air-airflow-db).
flowise 의 externalPostgresql.host 와 같은 규칙이다.
dip-questions.yaml
- git-sync 는 GIT_SYNC_*/GITSYNC_* 네 키를 모두 선언한다. 차트가 네 개를 각각
secretKeyRef 로 잡아서 하나라도 없으면 파드가 기동되지 않는다.
- connection 기본값 호스트는 $CATALOG_NAME-airflow-db-rw.$CATALOG_NAME.
차트가 data.metadataSecretName 의 connection 키를
AIRFLOW__DATABASE__SQL_ALCHEMY_CONN 에 그대로 주입하므로 이 값이 유일한 실효 값이다.
두 파일의 토큰 형식 차이는 의도한 것이다 — dip-questions 는 $CATALOG_NAME,
dip-values 는 {{ .Name }} 가 각 파일의 기존 관례다.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
etcd(bitnamilegacy 동결 미러) → etcd.enabled=false + 카탈로그 자체 etcd 차트를
externalEtcd 기본값으로 연결. adc·apisix-ingress-controller·apisix(paasup/apisix)
세 이미지는 SUSE BCI 자체 빌드로 교체 — 전부 벤더 등급만으로는 안 보이던
벤더 하향 등급 CVE(NVD 재평가 시 드러남)가 원인이었다.
- images/apisix-ingress-controller: 정적 링크 Go 모듈 취약 버전만 강제 업그레이드
- images/apisix: APISIX-Runtime(WASM·dubbo 등 커스텀 모듈 포함) 전체를 SUSE BCI
위에서 소스로 재현, keycloak-authz 플러그인 오버레이
- images/adc: 업스트림 빌더 스테이지는 그대로 두고 distroless 최종 베이스만
SUSE BCI+nodejs24 로 교체
scripts/build/patch-catalog-tag.py 의 TAG_BLOCK 이 점 구분 중첩 경로를 지원하도록
확장(apisix 서브차트 alias 때문에 필요).
세 이미지 모두 게이트 PASS(실효 CRITICAL/HIGH 0/0)와 배포 검증(테스트 클러스터)을
마쳤다.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
CVE 자체 빌드 이미지가 앱 버전까지 함께 올리며 두 카탈로그 버전이 서로 다른
컴포넌트 버전을 요구하는 복잡도가 생겨, 구버전을 유지하는 대신 최신 버전
하나로 정리한다.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
PR #18 이 카탈로그에 넣는 quay.io/keycloak/keycloak:26.6.4 가 게이트에서 차단
17건(실효 HIGH 17 / CRITICAL 0)이었다. sbom.yml 이 warn-only 라 PR 은 통과했지만
실제로는 게이트 실패 상태로 카탈로그에 들어간다.
## 상위 태그·베이스 OS 교체를 먼저 검토한 결과
차단 17건 중 12건이 배포본에 함께 실린 jar 다. keycloak 26.6.4 와 최신 26.7.1 의
quarkus.version 이 둘 다 3.33.2.1 이고 그 BOM 이 netty 4.1.135.Final /
jackson-bom 2.21.2 를 고정한다(keycloak pom.xml 두 태그 + quarkus BOM 실측).
필요한 수정 버전은 netty 4.1.136.Final, jackson 2.21.4 라 **상위 태그로도 풀리지
않고**, CVE 가 OS 패키지가 아니라 jar 자체라 **베이스 OS 교체도 통하지 않는다.**
jar 를 직접 교체하는 자체 빌드가 유일한 수단이다 — etcd 이미지의
`go.work replace golang.org/x/text` 와 같은 성격의 의존성 override.
## images/keycloak/
업스트림 quarkus/container/Dockerfile 을 기준으로 하되 셋이 다르다.
1. 런타임 rootfs 가 SUSE BCI. bci-micro 파일시스템을 **씨앗으로 깔고** 그 위에
zypper --installroot 로 설치한다. 업스트림 ubi-null.sh 처럼 별도 installroot 를
micro 위에 덮으면 micro 의 rpmdb 가 가려져 micro 자체 패키지가 SBOM 에서 통째로
사라진다 — CVE 가 주는 게 아니라 스캔 사각지대가 생긴다. 씨앗 방식으로 OS 패키지
65종이 정상적으로 잡히는 것을 SBOM 으로 확인했다.
2. 취약 jar 오버레이(overlay-jars.sh). netty 17종 → 4.1.136.Final, jackson
core/databind → 2.21.4, pgjdbc → 42.7.12. Quarkus fast-jar 의 클래스패스가
파일명을 그대로 참조하므로 **파일명은 유지하고 내용만** 바꾸고 sha1 로 검증한다.
trivy 는 jar 내부 메타데이터를 읽으므로 SBOM 에 새 버전이 정확히 잡힌다.
3. bin/client 제거. keycloak-admin-cli 가 jackson 을 shade 로 품은 uber-jar 라
교체가 불가능하다. 서버 JVM 이 로드하지 않는 독립 CLI 라 제거했다 — 업스트림
대비 유일한 기능적 차이이며 CUSTOM-README 에 대안을 적었다.
버전은 26.7.1 로 올렸다. 26.6.4 는 26.7.1(및 26.6.5)에서만 패치된 keycloak-services
HIGH 5건(CVE-2026-16102/16442/16443/15572/15573)에 취약하다. 차트(keycloakx 7.2.2)는
최신이고 그대로 둔다 — appVersion 26.6.4 는 codecentric 의 릴리스 캐던스 지연이다.
## 베이스 OS 정책 확정 (image-authoring.md 원칙 2 미결 해소)
SUSE BCI 로 통일하되 **버전은 이미지마다 실측해서 고른다.** BCI 16.0 이 나와 있지만
SLE_BCI 의 java-21-openjdk-headless 가 15.7 은 21.0.12, 16.0 은 21.0.11 이라 최신
베이스로 가면 CVE-2026-41254·CVE-2026-47063 이 오히려 남는다. bci-micro 에
sed·grep·find 가 셋 다 없다는 것과 SLE 패키지명 차이(tzdata→timezone 등)도 함께
기록했다.
## 실측 결과
로컬 빌드(linux/amd64) → verify.sh → SBOM → 전 심각도 스캔 → 게이트:
차단 17건 → **0건** (커버리지 자가진단 ok, OS=sles 15.7)
남은 1건 CVE-2025-59250 은 예외 등록했다 — 트리비가 같은 mssql-jdbc jar 하나로
컴포넌트를 둘 만들어(pom.properties 의 13.2.1.jre11 / 파일명의 13.2.1) 접미사가
잘린 쪽이 매칭된 파싱 오탐이다. 설치본은 FixedVersion 목록에 있는 13.2.1.jre11 이다.
dev 클러스터 격리 네임스페이스(kc-test-build)에 cnpg-cluster + keycloakx 로 실배포
검증: Pod Running, jdbc-postgresql 연결, liquibase 스키마 생성, admin 부트스트랩
(KC-SERVICES0077), apisix ingress 경유 OIDC discovery 200 / admin 토큰 발급 /
realm·client 생성(201) 까지 확인. 정리 시 Longhorn Volume 까지 삭제했다.
## custom-values.yaml ingress 수정
path 가 exact "/" 였다. apisix 에서는 루트만 매치되어 /realms/*, /admin/* 이 전부
404 가 난다 — airflow·superset·mlflow·lakekeeper 에서 이미 실측된 문제로 카탈로그가
regex 방식으로 통일돼 있다. path: /.* + k8s.apisix.apache.org/use-regex 로 맞췄고,
배포 검증에서 이 경로들이 실제로 뜨는 것을 확인했다.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1.0.0 에서 복사한 뒤 안 고친 차트 버전 표기(1.0.0)와 배포 경로를 1.1.0 으로
맞추고, 저장소에 실제로 존재하지 않는 doc/decisions·doc/analysis·doc/charts
경로 인용을 제거했다(리뷰 중 확인 — PR #17).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
dev 클러스터 격리 네임스페이스에 실제 배포해 검증하는 과정에서 두 가지
누락을 발견했다:
1. command/args 기본값이 둘 다 빈 배열이라, 지정하지 않으면 컨테이너가
인자 없는 kc.sh(도움말 출력, exit 0)로 끝나 CrashLoopBackOff가 된다.
2. hostname-strict 기본값이 true라 KC_HOSTNAME 을 지정하지 않으면
"hostname is not configured" 로 기동이 실패한다.
두 값 모두 custom-values.yaml에 추가하고, BUILD-README/CUSTOM-README에
실측 근거를 남겼다. 이후 admin 부트스트랩(KC-SERVICES0077), DB 마이그레이션,
admin REST API로 realm/client 생성까지 전부 정상 동작 확인.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
codecentric/keycloak(18.4.0, WildFly 기반, appVersion 17.0.1-legacy)이
bitnami/postgresql 서브차트를 조건부 의존성으로 포함해 bitnami 무료 배포
정책 변경 문제가 그대로 전이됐다. codecentric은 이 WildFly 차트를 더 이상
갱신하지 않고 Quarkus 기반 Keycloak(17+)용 별도 차트 keycloakx를 제공하며,
keycloakx는 서브차트 의존성이 전혀 없어(Chart.yaml에 dependencies 없음)
문제가 근본적으로 해소된다.
실제 소비자가 없어(문서 예시 표 한 줄 외 참조 없음) phased 전환 없이
keycloak/18.4.0을 같은 커밋에서 제거했다.
custom-values.yaml 작성 시 확인한 핵심 사항 — 이 차트의 http.relativePath
기본값이 구버전 WildFly Keycloak 호환용 "/auth"라, 명시적으로 "/"로
오버라이드해야 한다(안 하면 OIDC issuer/admin API 경로가 소비 앱들의
경로 접미사 없음 가정과 어긋난다). database.existingSecret/existingSecretKey
로 kubernetes.io/basic-auth 시크릿을 그대로 참조 가능함도 helm template로
확인했다.
Closes#1
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
앱별 부트스트랩 SQL 을 ConfigMap/Secret 참조로 실행할 수 있게 한다. CNPG CRD 에는
이미 있는 필드(operator 0.29.0/CRD 확인됨)인데 차트가 렌더하지 않아 values 로 쓸 수
없었다.
용도: 스키마 덤프처럼 큰 SQL 을 values 에 인라인하지 않고 ConfigMap 으로 넘기는 경우.
postInitApplicationSQL(인라인)과 시점·권한이 동일(클러스터 생성 직후 1회, 앱 DB 안에서
superuser) 하고 SQL 출처만 다르다. 1회성이라 비멱등 SQL(CREATE TABLE 등)을 그대로
넣어도 재실행되지 않는다.
- values.yaml: bootstrap.initdb.postInitApplicationSQLRefs 추가(configMapRefs/secretRefs,
기본 빈 배열)
- templates/cluster.yaml: 값이 있을 때만 렌더(있으면 렌더, 없으면 필드 자체가 안 나옴 —
기존 클러스터에 영향 없음을 렌더 테스트로 확인)
- CUSTOM-README.md: postInitApplicationSQL 과의 차이·참조 처리 순서(Secret 전체 →
ConfigMap 전체) 문서화
카탈로그 관례 파일(BUILD-README·CUSTOM-README 본문 대부분·dip-*.yaml·custom-values.yaml)은
1.0.0 에서 그대로 승계했다(diff 로 확인).
검증: 빈 값일 때 필드 미노출, configMapRefs 지정 시 정상 렌더, 기존 1.0.0
custom-values.yaml 로 1.1.0 렌더해도 문제없음(하위 호환) 확인.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
12.4.0 → 12.6.0 승계 시 BUILD-README/CUSTOM-README/custom-values 3개만 옮기고
카탈로그 관례 파일 5개를 빠뜨렸다. 12.4.0 에서 그대로 승계한다:
- argo-values.yaml
- dip-questions.yaml
- dip-resources-quotas.yaml
- dip-values.yaml
- dip-volumes-quotas.yaml
dip-*.yaml 은 카탈로그 전반의 관례다(25개 이상 차트, 총 100개 파일). 갱신 대상
7개 차트 중 이 파일들을 가진 것은 gitea 뿐이라 다른 차트는 영향이 없다.
내용은 버전 의존적이지 않아(리소스/볼륨 티어, questions, ApplicationSet 용 values)
수정 없이 그대로 옮겼다.
검증: 5개 파일 모두 12.4.0 과 12.6.0 에서 helm 렌더 결과가 동일하다. dip-values.yaml
(`{{ .Name }}`·`{{ .Domain }}` 미치환)과 argo-values.yaml(postgresql/postgresql-ha
동시 활성)은 양쪽 버전에서 똑같이 렌더 실패하는데, ApplicationSet 계층이 먼저
치환·조정하는 것을 전제로 한 파일이라 원래 helm 단독 렌더 대상이 아니다 —
이번 승계로 생긴 회귀가 아님을 12.4.0 대조로 확인했다.
차트 12개 렌더 재검증 12/12 통과.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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