Cloudera AI Inference(CAII) 와 AI Registry(Model Registry) 는 워크벤치와 달리 별도 Istio gateway 로 서비스되므로 apps 와일드카드 인증서를 공유하지 못하고 서비스 FQDN 하나짜리 인증서가 각각 필요하다. 이 문서는 사설 rootCA 로 두 인증서를 발급해 적용하는 절차, 사설 CA 를 Management Console 에 등록한 뒤 워크벤치 파드까지 전파되지 않아 x509 오류가 났던 문제의 해결, 그리고 모델 배포 시 내부 레지스트리 push 가 SSL 오류로 실패할 때 봐야 할 두 신뢰 계층을 정리한다.
도메인은 Cloudera AI → AI Registries → Details → Domain, Cloudera AI Inference service → Domain 에서 확인한다.
cd /root/certs
# rootCA 가 없을 때만
openssl genrsa -out rootCA.key 4096
openssl req -x509 -new -nodes -sha256 -days 3650 -key rootCA.key \
-subj "/C=KR/O=<org>/CN=Internal-RootCA" \
-addext "basicConstraints=critical,CA:TRUE" -addext "keyUsage=critical,keyCertSign,cRLSign" \
-out rootCA.pem
cat > mr.cnf <<'EOF'
[req]
distinguished_name = dn
req_extensions = ext
prompt = no
[dn]
CN = model-registry.apps.<base-domain>
[ext]
subjectAltName = @alt
[alt]
DNS.1 = model-registry.apps.<base-domain>
EOF
openssl genrsa -out mr.key 4096
openssl req -new -key mr.key -out mr.csr -config mr.cnf
openssl x509 -req -sha256 -days 730 -in mr.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial \
-extfile mr.cnf -extensions ext -out mr.crt
CAII 도 같은 형식으로 caii.cnf 를 만들어 caii.key / caii.crt 를 발급한다. 검증 후 secret 을 교체한다.
openssl verify -CAfile rootCA.pem mr.crt caii.crt
openssl x509 -in caii.crt -noout -subject -issuer -dates -ext subjectAltName
kubectl get secret ingress-default-cert-mr -n istio-ingress -o yaml > backup_mr_cert_secret.yaml
kubectl delete secret ingress-default-cert-mr -n istio-ingress
kubectl create secret tls ingress-default-cert-mr --cert=mr.crt --key=mr.key -o yaml --dry-run=client \
| kubectl -n istio-ingress apply -f -
kubectl get secret ingress-default-cert-caii -n istio-ingress -o yaml > backup_caii_cert_secret.yaml
kubectl delete secret ingress-default-cert-caii -n istio-ingress
kubectl create secret tls ingress-default-cert-caii --cert=caii.crt --key=caii.key -o yaml --dry-run=client \
| kubectl -n istio-ingress apply -f -
1.5.5 SP1 이상에서는 parcel 의 cml_utils.sh upload-cert-caii -c caii.crt -k caii.key 로도 적용된다. 서명에 쓴 rootCA.pem 은 Management Console → Administration → CA Certificates 에 반드시 등록한다. 등록이 빠지면 endpoint 목록 조회와 모델 import 가 실패한다.
증상은 워크벤치 web 파드 로그의 getResourcePool ... x509: certificate signed by unknown authority 이며, 콘솔 console-cdp 인증서를 검증할 CA 가 파드 안에 없어서 생긴다. 컨트롤 플레인의 cdp 네임스페이스 cdp-pvc-truststore configmap 에 CA 가 들어 있으면 등록 자체는 끝난 것이고, 워크벤치로의 전파만 남은 상태다.
kubectl -n cdp get configmap cdp-pvc-truststore -o jsonpath='{.data.*}' > /tmp/pvc-trust.pem
# 번들 안 인증서 subject 나열
awk -v cmd="openssl x509 -noout -subject" '/BEGIN/{c=""} {c=c$0 RS} /END/{print c | cmd; close(cmd)}' /tmp/pvc-trust.pem
전파는 워크벤치 UI 의 Actions → Refresh Certificate 로 한다. 이 액션은 truststore 번들을 가져와 private-cloud-ca-certs-pem-<n> / private-cloud-ca-certs-<n> configmap 에 병합 저장한 뒤 워크벤치 서비스를 재기동한다. 확인은 파드 안에서 콘솔 인증서 검증 코드가 0 이 되는지로 한다.
kubectl -n <ws> rollout status deployment web
kubectl -n <ws> exec deploy/web -c web -- openssl s_client -connect console-cdp.apps.<base-domain>:443 </dev/null 2>&1 | grep -i "verify return code"
kubectl -n <ws> logs -l app=web -c web --since=2m | grep -iE "getResourcePool|x509"
모델 배포는 외부 Nexus 에서 이미지를 받아 내부 레지스트리로 push 하는데, 이 push 는 워크벤치가 아니라 노드의 containerd/docker 가 TLS handshake 를 한다. 그래서 신뢰 계층이 둘로 나뉜다.
| 계층 | 대상 | 설정 위치 |
|---|---|---|
| A. 워크벤치 서비스 | Git, pip index, 사내 API 등 워크벤치가 호출하는 endpoint | 워크벤치 Details → CA Certificates 업로드 후 Refresh Certificate |
| B. 컨테이너 런타임 | 이미지 pull/push 대상 레지스트리 | 각 ECS 노드의 /etc/docker/certs.d/<registry-host>/ca.crt |
Nexus pull 은 되는데 내부 레지스트리 push 에서 SSL 오류가 나면 계층 B 문제다(릴리스 노트 DSE-44682). 노드에 CA 를 배치한 뒤 ctr 로 수동 pull 을 시험할 수 있다.
/opt/cloudera/parcels/ECS/docker/ctr --namespace=k8s.io -a /run/k3s/containerd/containerd.sock \
image pull --tlscacert <ca.pem> -u <user>:${PASSWORD} <registry-url>/<image>:<tag>