기술 · 실용 가이드
kubectl x509 ‘unknown authority’ 오류? 실제 신뢰 경로부터 증명하세요
자격 증명을 다시 발급하거나 TLS 검증을 끄기 전에 실제 kubeconfig, 클러스터 엔드포인트, CA, 프록시 경로와 제시된 체인을 확인합니다.
kubectl의 x509 오류만으로는 어떤 설정, 엔드포인트 또는 인증서 체인에서 실패했는지 알 수 없습니다. 먼저 현재 프로세스가 실제로 사용한 값을 증명해야 합니다.
이 가이드는 신뢰 설정을 바꾸기 전에 오래되거나 병합된 kubeconfig, 예상하지 못한 프록시, 교체된 API 서버 인증서, 호스트 이름 불일치를 구분합니다.
클라이언트, 오류와 실행 환경 고정하기
전체 오류, 명령, 시각, 클라이언트 버전과 셸 환경을 보관하고 HOME, KUBECONFIG 및 명시 플래그를 기록하되 자격 증명은 공유하지 않습니다.
처음부터 ~/.kube를 삭제하거나 모든 CA를 바꾸지 마세요. 오류만으로는 사용 파일, 엔드포인트, 프록시나 체인이 확정되지 않습니다.
실제 kubeconfig와 현재 context 증명하기
current-context와 config view --minify로 현재 클러스터와 사용자를 확인합니다. 여러 파일은 병합되고 먼저 설정한 맵 키가 우선합니다.
--raw는 보호된 로컬 세션에서만 사용하고 실제 출력과 예상 파일을 비교해 오래된 첫 파일, 다른 HOME, 서비스 계정을 배제합니다.
변경 없이 엔드포인트와 신뢰 앵커 추출하기
server URL, tls-server-name, proxy-url, CA 경로와 CA data 존재 여부를 기록합니다. 내장 데이터는 CA 파일보다 우선합니다.
내장 CA는 권한을 제한한 임시 파일에만 디코딩하고 주체, 발급자, 유효 기간과 지문을 기록합니다.
같은 경로에서 실제 인증서 확인하기
실패한 것과 같은 네트워크, VPN, 컨테이너에서 검사하고 OpenSSL -connect, -servername, -verify_return_error를 사용합니다.
proxy-url과 HTTPS_PROXY, HTTP_PROXY, NO_PROXY를 확인하고 leaf의 SAN, 발급 체인과 지문을 예상 엔드포인트와 비교합니다.
수리 전 불일치 분류하기
오래된 관리 설정, 잘못 병합된 context, CA data 덮어쓰기, 중간 인증서 누락, 프록시 인증서와 SNI 불일치를 구분합니다.
예상하지 못한 엔드포인트의 leaf를 무작정 신뢰하지 말고 신뢰 앵커는 소유자나 인증된 제어 채널에서 받습니다.
명확한 신뢰 계약 하나만 수리하기
관리형 클러스터는 공식 명령으로 자격 증명을 갱신하고 신구 항목을 비교하며 자체 관리에서는 검증된 발급 CA를 대상 항목에 설치합니다.
불필요한 프록시를 수정하고 필요하면 조직의 인증된 절차로 CA를 받습니다. 검증 비활성화는 사용하지 않습니다.
원래 환경으로 검증하고 롤백 증거 보관하기
같은 kubeconfig, context, 네트워크 경로와 원래 명령으로 다시 테스트해 엔드포인트와 발급자가 목표 클러스터와 일치하는지 확인합니다.
변경 전후 해시, CA 지문, 엔드포인트, 프록시 결정, 갱신 명령과 롤백 파일을 기록하고 임시 CA를 안전하게 지웁니다.
