wbsong111
18044210f6
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>
75 lines
3.4 KiB
Bash
Executable File
75 lines
3.4 KiB
Bash
Executable File
#!/usr/bin/env bash
|
|
# apisix 이미지 기능 검증 — 호스트에서 bash 로 실행된다(build-hardened-image.sh 가
|
|
# `env TAG=... PLATFORM=... bash verify.sh` 형태로 호출한다).
|
|
#
|
|
# 최종 베이스가 bci-base 라 bash/coreutils/awk 가 있다 — 게스트 셸 스크립트를 그대로
|
|
# 주입한다. 단순 --help 스모크가 아니라 실제로 nginx worker 를 기동해 APISIX 라우터가
|
|
# HTTP 요청에 응답하는지까지 확인한다(standalone/yaml config, etcd 불필요) — 15개
|
|
# 커스텀 nginx 모듈 + ~90개 Lua 플러그인(lua-resty-saml 같은 C 확장 포함) 로딩까지
|
|
# 실제로 거치는 유일한 방법이다. keycloak-authz 커스텀 플러그인은 실제 Keycloak 연동이
|
|
# 필요해 이 스모크 범위 밖 — 이건 dev 클러스터 배포 검증(.claude/deploy-test-procedure.md)
|
|
# 이 담당한다.
|
|
#
|
|
# 마지막 줄에 VERIFY-OK 를 출력하면 통과다. build-hardened-image.sh 가 그것으로 판정한다.
|
|
set -e
|
|
|
|
TAG="${TAG:?TAG 환경변수가 필요하다}"
|
|
PLATFORM="${PLATFORM:-linux/amd64}"
|
|
|
|
echo "== apisix version =="
|
|
OUT="$(docker run --rm --platform "$PLATFORM" --entrypoint sh "$TAG" -c '
|
|
export PATH=$PATH:/usr/local/openresty/luajit/bin:/usr/local/openresty/nginx/sbin:/usr/local/openresty/bin
|
|
/usr/bin/apisix version
|
|
')"
|
|
echo " $OUT"
|
|
case "$OUT" in
|
|
*3.17.0*) ;;
|
|
*) echo "FAIL: apisix version 출력에 3.17.0 이 없다"; exit 1 ;;
|
|
esac
|
|
|
|
echo "== nginx 설정 문법 검사 (init + nginx -t) =="
|
|
CONTAINER="verify-apisix-$$"
|
|
docker run -d --rm --platform "$PLATFORM" --name "$CONTAINER" --entrypoint sh "$TAG" -c '
|
|
export PATH=$PATH:/usr/local/openresty/luajit/bin:/usr/local/openresty/nginx/sbin:/usr/local/openresty/bin
|
|
cd /usr/local/apisix
|
|
export APISIX_STAND_ALONE=true
|
|
cat > conf/config.yaml <<EOF
|
|
deployment:
|
|
role: data_plane
|
|
role_data_plane:
|
|
config_provider: yaml
|
|
EOF
|
|
cat > conf/apisix.yaml <<EOF
|
|
routes:
|
|
#END
|
|
EOF
|
|
/usr/bin/apisix init >/tmp/init.log 2>&1
|
|
/usr/local/openresty/nginx/sbin/nginx -p /usr/local/apisix -t >>/tmp/init.log 2>&1
|
|
exec /usr/local/openresty/bin/openresty -p /usr/local/apisix -g "daemon off;"
|
|
' >/dev/null
|
|
trap 'docker rm -f "$CONTAINER" >/dev/null 2>&1 || true' EXIT
|
|
|
|
echo "== HTTP 응답 대기 (최대 15초) =="
|
|
# curl 은 연결 자체가 실패해도 %{http_code} 로 "000" 을 찍는다 — 빈 문자열이 아니라서
|
|
# `[ -n "$CODE" ]` 만으로는 연결 실패를 통과로 오판한다(2026-08-12 실측: 파이프라인
|
|
# 첫 실행에서 "HTTP 000" 인데도 VERIFY-OK 가 나온 버그). "000" 은 명시적으로 실패로 친다.
|
|
ok=0
|
|
for i in $(seq 1 15); do
|
|
CODE="$(docker run --rm --platform "$PLATFORM" --network "container:$CONTAINER" curlimages/curl:latest \
|
|
-s -o /dev/null -w '%{http_code}' -m 2 http://127.0.0.1:9080/ 2>/dev/null || true)"
|
|
if [ -n "$CODE" ] && [ "$CODE" != "000" ]; then ok=1; break; fi
|
|
sleep 1
|
|
done
|
|
if [ "$ok" != "1" ]; then
|
|
echo "FAIL: 15초 내에 9080 포트가 유효한 HTTP 응답을 하지 않았다 (마지막 시도: '${CODE:-없음}')"
|
|
docker logs "$CONTAINER" 2>&1 | tail -40
|
|
exit 1
|
|
fi
|
|
echo " HTTP $CODE (라우트가 없어 404 가 정상 — nginx/APISIX 라우터가 실제로 요청을 처리했다는 뜻)"
|
|
case "$CODE" in
|
|
404) ;;
|
|
*) echo "FAIL: 예상한 404(라우트 없음)가 아니라 $CODE 가 나왔다 — 로그 확인 필요"; docker logs "$CONTAINER" 2>&1 | tail -40; exit 1 ;;
|
|
esac
|
|
|
|
echo "VERIFY-OK"
|