새 팀에 합류해서 “클러스터 인증서 문제가 있다”는 이야기를 들었을 때, 가장 먼저 해야 할 일은 (1) 클러스터가 어떤 방식으로 프로비저닝 되었는지 파악하고, 그 다음 (2) 실제로 사용 중인 인증서 목록을 “구성 파일에서” 역추적한 뒤, (3) 각 인증서를 열어서(SAN/Issuer/만료일/조직) 검증하는 것입니다.

이 글은 강의 흐름 그대로 kubeadm 기반 클러스터를 기준으로 정리합니다. (kubeadm은 control plane을 “static pod”로 띄우는 구성이 일반적입니다.)

1) 먼저 “클러스터 설치 방식”부터 확인해야 하는 이유

인증서 파일의 위치/관리 방식이 설치 방식에 따라 달라집니다.

  • 수동 설치(바이너리 직접 설치, systemd 서비스로 구동)
    → 인증서 경로/이름이 환경마다 제각각일 수 있고, systemd 로그로 추적
  • kubeadm 설치(가장 흔함)
    → 정해진 표준 경로가 많음
    → control plane은 대개 /etc/kubernetes/manifests/ 아래 static pod manifest로 존재
  • Managed K8s(EKS/GKE/AKS 등)
    → control plane 인증서/구성은 클라우드가 관리(사용자가 직접 못 보는 영역이 많음)

이 글은 kubeadm을 대상으로 합니다.

2) kubeadm 클러스터에서 인증서가 “대체로 있는 곳”

2.1 인증서/키 파일

  • 보통: /etc/kubernetes/pki/
  • etcd 관련: /etc/kubernetes/pki/etcd/

대표 예시:

  • ca.crt, ca.key (클러스터 CA)
  • apiserver.crt, apiserver.key
  • apiserver-etcd-client.crt, apiserver-etcd-client.key
  • apiserver-kubelet-client.crt, apiserver-kubelet-client.key
  • front-proxy-ca.crt, front-proxy-client.crt 등(환경에 따라)

2.2 kubeconfig(클라이언트 인증서가 “파일이 아니라 kubeconfig 안에 들어있는” 경우)

  • /etc/kubernetes/admin.conf
  • /etc/kubernetes/controller-manager.conf
  • /etc/kubernetes/scheduler.conf
  • /etc/kubernetes/kubelet.conf

여기에는 client-certificate-data, client-key-data, certificate-authority-data가 base64로 포함되는 경우가 많습니다.

3) “사용 중인 인증서 목록”을 만드는 방법 (가장 안전한 방법)

핵심은 “실제 실행/설정 파일에서 참조하는 인증서 경로를 뽑는 것”입니다.
“어딘가에 파일이 있다”가 아니라, 지금 프로세스가 어떤 파일을 쓰는지가 중요합니다.

3.1 kube-apiserver에서 찾기

kubeadm은 보통 아래 manifest에 kube-apiserver 실행 옵션이 있습니다.

sudo cat /etc/kubernetes/manifests/kube-apiserver.yaml

여기서 아래 플래그를 찾아서 경로를 수집합니다(예시):

  • --tls-cert-file=...
  • --tls-private-key-file=...
  • --client-ca-file=...
  • --etcd-cafile=...
  • --etcd-certfile=...
  • --etcd-keyfile=...
  • --kubelet-client-certificate=...
  • --kubelet-client-key=...

이렇게 “용도별”로 어떤 인증서가 쓰이는지 확정할 수 있습니다.

3.2 etcd에서 찾기

sudo cat /etc/kubernetes/manifests/etcd.yaml

보통 아래가 보입니다.

  • --cert-file=...
  • --key-file=...
  • --trusted-ca-file=...
  • HA라면 peer 관련:
    • --peer-cert-file=...
    • --peer-key-file=...
    • --peer-trusted-ca-file=...

3.3 controller-manager / scheduler / kubelet

  • controller-manager: /etc/kubernetes/manifests/kube-controller-manager.yaml
  • scheduler: /etc/kubernetes/manifests/kube-scheduler.yaml
  • kubelet은 보통:
    • systemd 서비스 + /var/lib/kubelet/config.yaml
    • 또는 /etc/kubernetes/kubelet.conf를 사용

4) “엑셀(또는 표) 점검 템플릿” 추천 컬럼

강의에서 말한 스프레드시트는 실무에서도 아주 좋습니다. 최소 아래 컬럼이면 충분합니다.

  • Component (예: kube-apiserver)
  • Purpose (Serving / Client-to-etcd / Client-to-kubelet 등)
  • File Path (예: /etc/kubernetes/pki/apiserver.crt)
  • Subject(CN) / Organization(O) / OU
  • SAN(DNS/IP)
  • Issuer (누가 서명했나)
  • Not Before / Not After (유효기간)
  • Days Remaining (남은 일수)
  • Notes (의심 포인트)

5) 각 인증서를 “열어서” 확인하는 방법 (openssl)

5.1 인증서 내용 보기

openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text

여기서 확인할 핵심 섹션:

(1) Subject (CN/O/OU)

  • “이 인증서의 신원”
  • 예: CN = kube-apiserver

(2) Issuer

  • “누가 서명했는가(어느 CA인가)”
  • 예: CN = Kubernetes 또는 CN = Kubernetes-CA 등 환경별

(3) Validity

  • Not Before, Not After (만료 여부)

(4) X509v3 Subject Alternative Name (SAN)

  • API 서버는 특히 SAN이 중요
    예: kubernetes, kubernetes.default.svc, 서비스 IP 등
  • SAN 누락은 “TLS 검증 실패”의 단골 원인

5.2 한 번에 핵심만 뽑기(요약)

openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout \
  -subject -issuer -dates

SAN만 따로:

openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text \
  | sed -n '/Subject Alternative Name/,+2p'

6) kubeadm에서는 “만료 점검”을 더 쉽게 하는 명령도 있음

kubeadm 설치 클러스터라면 아래가 매우 빠릅니다.

sudo kubeadm certs check-expiration
  • 주요 인증서들의 만료일/잔여일을 요약해서 보여줍니다.
  • 다만 “정확히 어떤 구성 파일에서 참조 중인지”까지 대체하진 못하므로,
    (구성에서 경로 수집) + (kubeadm 요약) + (openssl 상세) 조합이 가장 좋습니다.

7) 문제가 의심되면 어디서 로그를 보나?

인증서 문제는 보통 이런 형태로 나타납니다.

  • x509: certificate has expired or is not yet valid
  • x509: certificate signed by unknown authority
  • certificate is valid for ..., not ... (SAN mismatch)
  • tls: bad certificate (mTLS에서 클라이언트 인증서 문제)

7.1 API 서버/etcd가 살아있으면: kubectl logs

kubeadm의 control plane은 static pod로 뜨는 경우가 많아, 아래처럼 봅니다.

kubectl -n kube-system get pods
kubectl -n kube-system logs <kube-apiserver-pod-name>
kubectl -n kube-system logs <etcd-pod-name>

7.2 API 서버가 죽어서 kubectl이 안 되면: kubelet + 컨테이너 런타임 로그로 내려가기

요즘은 Docker가 아니라 containerd인 경우가 많습니다.

kubelet 로그

sudo journalctl -u kubelet -n 200 --no-pager

containerd(crictl)로 컨테이너 로그 확인

sudo crictl ps -a | grep -E 'kube-apiserver|etcd|kube-scheduler|kube-controller-manager'
sudo crictl logs <CONTAINER_ID>

(만약 구형으로 Docker 런타임이면 docker ps / docker logs를 쓰는 환경도 있습니다.)

8) 점검 체크리스트(실무용)

  1. 구성 파일에서 실제 참조 인증서 경로 수집
    • /etc/kubernetes/manifests/*.yaml
    • /etc/kubernetes/*.conf, /var/lib/kubelet/config.yaml
  2. 각 인증서에 대해:
    • Subject(CN/O/OU)가 의도와 맞는지
    • SAN이 충분한지(특히 apiserver)
    • Issuer가 “클러스터가 신뢰하는 CA”인지
    • 만료 여부/잔여일
  3. 실패 시 로그:
    • kubectl logs → 안 되면 journalctl -u kubelet + crictl logs

 

**adm기준 /etc/kubernetes/pki/ca.crt가 쿠버네티스가 제공하는 인증서이지만 보안이 뚫릴 경우 위험하므로 etcd는 etcd용 별도로 /etc/kubernetes/pki/etcd/ca.crt가 따로 있음.

 

 

Practice Test: https://uklabs.kodekloud.com/topic/practice-test-view-certificate-details-2/

'CKA' 카테고리의 다른 글

Security - Kubeconfig  (0) 2026.01.01
Security - CSR API  (0) 2026.01.01
Security - 인증서 생성 방법  (0) 2026.01.01
Security - TLS in Kubernetes  (0) 2026.01.01
Security - SSH 프로세스 정리  (0) 2026.01.01

티스토리툴바