Kubernetes 내부에서 TLS와 인증서 처리 방식

Kubernetes는 클러스터 내의 API Server, kubelet, controller-manager, scheduler 등 다양한 컴포넌트들이 네트워크를 통해 통신한다. 이 통신은 모두 TLS(Transport Layer Security) 기반으로 암호화되며, 클러스터 내에서 안전한 통신과 인증을 위해 인증서가 필수적으로 사용된다.

 

이번 글에서는 Kubernetes에서 TLS 인증서가 어떻게 발급·검증·갱신되는지, 그리고 이를 구성하는 핵심 메커니즘을 알아보자.

왜 Kubernetes에 TLS가 필요한가?

쿠버네티스는 기본적으로 Zero Trust 네트워크 모델을 가정한다. 즉, 내부 통신이라도 암호화하지 않으면 안전하다고 보지 않는다.

TLS는 다음 두 가지 이유로 필수다.

1. 암호화(Encryption) : API 요청과 응답이 암호화되어 중간자 공격(MITM)이나 패킷 스니핑 방지.
2. 상호 인증(Mutual TLS, mTLS) : 단순히 서버의 신원 확인뿐 아니라, 클라이언트 인증서를 통해 요청 주체가 인증된 구성 요소인지 검증.

Kubernetes의 PKI 구조

쿠버네티스는 자체 내장 PKI(Public Key Infrastructure)를 사용한다. 이 PKI의 최상위에는 Cluster CA(Certificate Authority)가 존재한다.

주요 인증서 발급 대상

• API Server: 클러스터의 중심 엔드포인트
• kubelet: 각 노드에서 Pod 실행과 상태 보고 담당
• Controller Manager / Scheduler: 클러스터 제어 로직 실행
• etcd: 클러스터 상태 저장소
• Service Accounts: Pod 내 애플리케이션 인증용 토큰(JWT 기반)

TLS 인증서 발급과 부여 과정

클러스터 초기 생성 시

kubeadm으로 클러스터를 생성할 경우

1. CA 키와 인증서 생성 (ca.crt, ca.key)
2. API Server, kubelet, 컨트롤러 등 각 컴포넌트별 서버 인증서 발급
3. 각 인증서에 포함되는 Subject Alternative Name(SAN) 설정
   - API Server는 kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster.local 등의 DNS 이름 포함
4. 모든 노드/컴포넌트는 CA 인증서를 신뢰 저장소에 추가

# 예시: kubeadm에서 CA 생성
kubeadm init phase certs all

컴포넌트 간 통신에서의 mTLS 예시

예시: API Server ↔ kubelet

1. API Server가 kubelet에 요청
   → API Server는 CA로 서명된 클라이언트 인증서를 사용
2. kubelet은 API Server의 인증서를 검증 (CA 공개키로 서명 확인)
3. kubelet도 자신의 클라이언트 인증서를 제시
4. API Server는 kubelet 인증서를 검증
5. 양쪽 모두 검증이 끝나면 TLS 세션이 수립

Kubernetes에서 인증서 저장 위치

kubeadm 기준 기본 경로는 /etc/kubernetes/pki 다.

파일명	설명
ca.crt, ca.key	클러스터 CA 인증서와 개인키
apiserver.crt, apiserver.key	API Server TLS 인증서/키
apiserver-kubelet-client.crt	API Server가 kubelet과 통신 시 사용하는 클라이언트 인증서
front-proxy-ca.crt	Aggregated API 서버용 CA
etcd/ca.crt	etcd 전용 CA

인증서 갱신과 관리

유효기간

• 기본적으로 kubeadm이 발급한 인증서 유효기간은 1년 (--cert-expiration으로 변경 가능).
• 1년이 지나면 API Server 기동 불가 → 사전에 갱신 필요.

갱신 방법

# 인증서 갱신
sudo kubeadm cert renew all

# 만료일 확인
sudo kubeadm cert check-expiration

자동 갱신

• kubelet 인증서는 kubelet 자체적으로 자동 갱신 (기본 1년)
• API Server, Controller Manager 등은 kubeadm 기반 설치 시 수동 갱신 필요 (단, kubeadm 1.15+에서 일부 자동화 가능)

Ingress와 애플리케이션 레벨 TLS

쿠버네티스 내부 통신 외에도 사용자 요청 → Ingress → Service → Pod 경로에서도 TLS를 적용할 수 있다.

• Ingress Controller + TLS Secret

kubectl create secret tls my-tls-secret \
  --cert=./tls.crt \
  --key=./tls.key

• Ingress 리소스에서

tls:
  - hosts:
      - example.com
    secretName: my-tls-secret

cert-manager를 사용하면 자동 발급/갱신(Let’s Encrypt) 가능

정리

Kubernetes 내부 TLS는 크게 두 계층에서 작동한다.

1. 클러스터 내부 컴포넌트 간 mTLS
   - API Server ↔ kubelet, etcd 등
   - CA 기반 상호 인증
2. 사용자 트래픽(애플리케이션 레벨) TLS
   - Ingress, Service, Pod 레벨에서 HTTPS 지원
   - 외부 CA(Let’s Encrypt, 기업 CA) 또는 내부 CA 발급 인증서 사용

이 두 레이어가 결합되어 엔드투엔드 암호화와 안전한 인증을 보장한다.