kubectl: x509: certificate signed by unknown authority

안녕하세요, BlueByte입니다. 평범하게 kubectl get pods를 실행했는데 워크로드 대신 Unable to connect to the server: x509: certificate signed by unknown authority가 뜹니다. 클러스터가 죽은 게 아닙니다 — kubectl은 API 서버에 도달해 서버가 제시한 TLS 인증서를 검사했고, 그것을 신뢰하지 못해 거부한 것입니다. 오늘은 메시지 변형들, kubeconfig 안의 certificate authority가 왜 더 이상 맞지 않게 됐는지, 서버가 실제로 보내는 인증서를 보는 법, 원인별 해결, 그리고 재발을 막는 법까지 하나씩 짚어보겠습니다.

kubectl이 실제로 출력하는 x509 오류들

같은 TLS 검사에서 나오는 세 가지 관련 메시지가 있습니다. 가장 흔한 것:

Unable to connect to the server: x509: certificate signed by unknown authority

kubectl이 연결되고, API 서버가 서빙 인증서를 보냈으며, kubectl은 그 인증서를 kubeconfig에 기록된 certificate authority(CA)까지 거슬러 올라가 확인하지 못했습니다. 가까운 친척 둘도 함께 나타납니다:

Unable to connect to the server: x509: certificate has expired or is not yet valid
Unable to connect to the server: x509: certificate is valid for 10.96.0.1, not 192.168.49.2

첫 번째는 서버 인증서가 유효 기간을 벗어났다는 뜻이고, 두 번째는 인증서 자체는 진짜지만 여러분이 접속하는 server: 주소와 다른 이름·IP로 발급됐다는 뜻입니다. 세 가지 모두 kubectl이 엔드포인트를 신뢰하지 않겠다는 것이지, 클러스터가 깨진 것은 아닙니다.

CA가 더 이상 맞지 않게 된 이유

"unknown authority" 형태를 만드는 구체적인 원인은 몇 가지입니다:

• 클러스터가 재구축됐거나 인증서가 재생성됨 — minikube delete && minikube start, 다시 만든 kind 클러스터, 재프로비저닝된 매니지드 클러스터는 모두 새 CA를 발급하지만, kubeconfig에는 여전히 옛 certificate-authority-data가 남아 있습니다.
• 엉뚱한 클러스터를 가리키고 있음 — 오래된 current-context이거나, 다른 API 서버 앞의 로드 밸런서·프록시로 해석되는 server:.
• 사내 TLS 검사 프록시가 여러분과 서버 사이에 끼어, 브라우저는 신뢰하지만 kubectl은 신뢰하지 않는 CA로 연결을 다시 서명함.
• self-signed 서버인데 kubeconfig에 CA가 아예 없음 — kubectl이 대조할 대상이 없음.

kubeconfig가 실제로 쓰는 서버와 CA 확인하기

어느 context가 활성인지 추측하지 말고 kubectl에 물어보세요:

kubectl config view --minify

clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://192.168.49.2:8443
  name: minikube
current-context: minikube

--minify는 출력을 현재 context 하나로 좁혀, kubectl이 접속하는 정확한 server와 CA가 임베드돼 있는지를 보여줍니다. kubectl config get-contexts는 모든 context를 나열해, 다른 클러스터에서 남은 것이 아니라 의도한 context에 있는지 확인하게 해줍니다.

서버가 실제로 제시하는 인증서 읽기

엔드포인트가 실제로 보내는 것을 OpenSSL로 직접 봅니다:

openssl s_client -connect 192.168.49.2:8443 -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -subject -dates

issuer=CN=kubernetes
subject=CN=kube-apiserver
notBefore=... notAfter=...

issuer가 클러스터 CA가 아니라 사내 프록시 CA라면, 경로에 MITM 프록시가 있는 것입니다. notAfter가 과거라면 인증서가 만료된 것입니다. issuer는 맞아 보이는데 kubectl이 여전히 거부한다면, kubeconfig에 임베드된 CA가 오래된 것입니다.

원인별 해결: kubeconfig 갱신 또는 올바른 CA 임베드

재구축·매니지드 클러스터라면 base64를 손으로 고치지 말고 출처에서 새 kubeconfig를 받으세요:

minikube update-context                                # minikube
aws eks update-kubeconfig --name mycluster             # EKS
gcloud container clusters get-credentials mycluster    # GKE

직접 관리하는 클러스터라면, context가 올바른 CA 파일을 가리키게 하고 설정과 함께 이동하도록 임베드합니다:

kubectl config set-cluster mycluster \
  --server=https://192.168.49.2:8443 \
  --certificate-authority=/path/to/ca.crt \
  --embed-certs=true

사내 프록시라면 kubectl이 읽는 번들에 프록시 CA를 추가하거나 API 엔드포인트를 검사에서 우회시키세요 — 검증을 전역으로 끄지는 마세요. 개발 전용 최후 수단으로 검사를 건너뛸 수는 있지만, 그것은 이 오류가 주는 바로 그 보호를 끄는 일임을 이해해야 합니다:

kubectl config set-cluster mycluster --insecure-skip-tls-verify=true

실제 사례: 재구축된 minikube 클러스터

망가진 로컬 클러스터를 초기화하려고 minikube delete && minikube start를 실행한 뒤 kubectl get pods가 x509: certificate signed by unknown authority를 던졌습니다. kubectl config view --minify에는 같은 server: https://192.168.49.2:8443이 있어 주소는 문제가 없었습니다 — 다만 새 클러스터의 CA를 캐시된 kubeconfig가 몰랐던 것입니다. minikube update-context가 그 context의 certificate-authority와 클라이언트 인증서를 다시 써 넣었고, 다음 kubectl get pods가 노드 목록을 반환했습니다. 1분도 안 걸렸고, base64 덩어리를 손으로 편집하지 않았습니다.

Unauthorized·connection refused와 어떻게 다른가

x509: ...는 서버의 정체에 관한 것으로, 인증을 받기 전 TLS 핸드셰이크 단계에서 실패합니다. error: You must be logged in to the server (Unauthorized)는 반대입니다: TLS 검사는 통과했지만 여러분의 자격 증명이 거부됐습니다. The connection to the server ... was refused는 더 앞 단계로, API 포트에서 아무도 응답하지 않아 검사할 인증서 자체가 없었던 것입니다. 셋 중 무엇을 받았는지 읽으면 CA를 볼지, 자격 증명을 볼지, 서버가 살아 있는지부터 볼지가 갈립니다.