Security - TLS in Kubernetes

Kubernetes 클러스터는 컴포넌트가 많고, 그 컴포넌트들이 서로 계속 통신합니다. 이 통신이 평문이거나, “가짜 서버/가짜 클라이언트”가 끼어들 수 있으면(중간자 공격, MITM) 클러스터는 사실상 뚫린 겁니다.
그래서 Kubernetes는 클러스터 내부 통신에 TLS를 쓰고, 더 나아가 대부분의 중요한 통신은 mTLS(서로 인증하는 TLS) 구조로 설계됩니다.

이 글은 아래 순서로 정리합니다.

1. Kubernetes에서 TLS가 필요한 이유
2. “서버 인증서 / 클라이언트 인증서 / CA”가 각각 무슨 역할인지
3. 어떤 컴포넌트가 서버/클라이언트인지(누가 누구와 통신하는지)
4. 인증서가 많아지는 이유와, 파일 이름 규칙을 헷갈리지 않는 방법
5. (실무) kubeadm 클러스터에서 실제 인증서 파일/구성 확인법
6. 공격 시나리오(MITM/키 유출)와 방어 포인트

---

1) Kubernetes에서 TLS가 필요한 이유

클러스터에는 크게 다음이 있습니다.

• Control Plane: kube-apiserver, etcd, controller-manager, scheduler
• Worker Node: kubelet, kube-proxy (+ 파드/컨테이너)

이들은 네트워크로 계속 통신합니다. 여기서 지켜야 할 것은 3가지입니다.

• 기밀성: 트래픽을 도청해도 내용을 못 읽게
• 무결성: 중간에서 조작하면 들키게
• 인증: “진짜 kube-apiserver / 진짜 etcd / 진짜 kubelet / 진짜 컴포넌트”인지 확인

TLS는 이 3가지를 묶어서 해결하는 표준 방식입니다.

---

2) 인증서 종류 3개: Server / Client / CA

강의에서 말한 “세 가지 인증서”를 Kubernetes 관점에서 정리하면 아래입니다.

2.1 서버 인증서(Server Certificate)

• “내가 서버다”를 증명하고, TLS 연결을 열기 위한 인증서
• 예: kube-apiserver(HTTPS), etcd(HTTPS), kubelet(HTTPS)

2.2 클라이언트 인증서(Client Certificate)

• 서버에 접근하는 쪽이 “내가 누구다”를 증명하는 인증서
• 예: 관리자(kubectl), scheduler, controller-manager, kube-proxy, (API 서버가 etcd에 붙을 때의 클라이언트 신원)

2.3 CA 인증서(Certificate Authority, 루트/중간 인증서)

• 서버/클라이언트 인증서에 “이 인증서는 믿을 만하다”라고 서명(sign) 해주는 상위 인증서
• 클러스터에서 가장 중요한 키는 CA의 개인키(ca.key) 입니다. 이게 유출되면 거의 “클러스터 신분증 발급기”가 털린 겁니다.

---

3) Kubernetes에서 “누가 서버고 누가 클라이언트인지” 한 번에 보기

아래는 핵심 통신만 뽑은 관계입니다.

3.1 kube-apiserver: 클러스터의 중심 서버

• 외부(관리자 kubectl, CI/CD, 다른 컴포넌트)가 붙는 HTTPS 서버
• 따라서 서버 인증서가 필요합니다.

그리고 kube-apiserver는 “서버”이면서 동시에 “클라이언트”가 되기도 합니다.

• kube-apiserver → etcd : API 서버가 etcd에 붙는 클라이언트
• kube-apiserver → kubelet : API 서버가 각 노드 kubelet에 붙는 클라이언트

즉 API 서버는:

• 외부에겐 서버(Serving cert)
• etcd/kubelet에겐 클라이언트(Client cert)
  가 동시에 됩니다.

3.2 etcd: 저장소 서버

• etcd는 HTTPS로 동작하며 서버 인증서가 필요합니다.
• kube-apiserver가 etcd에 붙을 때는, etcd 관점에서 kube-apiserver는 클라이언트이므로 클라이언트 인증서가 필요합니다.

(etcd를 HA로 구성하면 etcd끼리도 통신(peer)하므로 peer용 인증서도 따로 존재합니다.)

3.3 kubelet: 워커 노드의 서버이자 클라이언트

• kubelet은 노드에서 HTTPS 엔드포인트(서버) 를 열어 API 서버가 노드 상태/로그/exec 등을 하도록 합니다 → kubelet 서버 인증서
• kubelet도 API 서버에 보고/등록을 해야 하므로 API 서버에 붙는 클라이언트입니다 → kubelet 클라이언트 인증서

3.4 scheduler / controller-manager / kube-proxy: API 서버에 붙는 클라이언트

이 컴포넌트들은 API 서버에 요청을 보내야 일을 합니다.
API 서버 입장에선 “외부 사용자(kubectl)”와 다를 바 없는 클라이언트이므로 각각 클라이언트 인증서가 필요합니다.

---

4) “인증서 파일 이름 규칙”은 힌트일 뿐이고, 진짜는 “파일 내용”이다

강의에서 나온 규칙은 초보자에게 도움이 됩니다.

• 대체로 인증서(공개키 포함): .crt 또는 .pem
• 대체로 개인키: .key 또는 파일명에 key 포함

다만 실무에서 꼭 기억해야 할 점이 있습니다.

• .pem은 ‘포맷(컨테이너)’ 입니다.
  .pem 안에 인증서가 들어갈 수도 있고, 개인키가 들어갈 수도 있습니다.
• 그래서 “이 파일이 인증서인지 개인키인지”는 확장자보다 내용으로 판단하는 게 안전합니다.

확인 명령:

# 인증서(공개키 포함)면 가능
openssl x509 -in something.crt -text -noout

# 개인키면 가능
openssl pkey -in something.key -text -noout

---

5) (실무) kubeadm 클러스터에서 인증서가 실제로 어디 있고, 뭐가 뭔지

kubeadm 기반 클러스터라면 보통 여기 있습니다.

• /etc/kubernetes/pki/

대표적으로 다음이 자주 나옵니다(환경마다 약간 다를 수 있음).

5.1 클러스터 CA

• ca.crt, ca.key : 기본 CA (API 서버/클라이언트 인증서 서명에 사용)

5.2 kube-apiserver (서버 역할)

• apiserver.crt, apiserver.key : API 서버가 HTTPS 서버로 동작할 때 사용

5.3 kube-apiserver가 “클라이언트”로서 쓰는 것들

• apiserver-etcd-client.crt, apiserver-etcd-client.key : API 서버가 etcd에 붙을 때
• apiserver-kubelet-client.crt, apiserver-kubelet-client.key : API 서버가 kubelet에 붙을 때

5.4 etcd (서버/피어/헬스체크)

• /etc/kubernetes/pki/etcd/ca.crt, ca.key
• /etc/kubernetes/pki/etcd/server.crt, server.key
• /etc/kubernetes/pki/etcd/peer.crt, peer.key
• /etc/kubernetes/pki/etcd/healthcheck-client.crt, healthcheck-client.key

5.5 controller-manager / scheduler / admin / kube-proxy (클라이언트 인증서)

이들은 보통 “인증서 파일” 자체보다 kubeconfig 안에 embedded(내장)되어 있는 형태로 많이 봅니다.

• /etc/kubernetes/controller-manager.conf
• /etc/kubernetes/scheduler.conf
• /etc/kubernetes/admin.conf
• /etc/kubernetes/kubelet.conf
• /etc/kubernetes/kube-proxy.conf (환경에 따라)

각 kubeconfig 안에는 다음이 들어갑니다.

• client-certificate-data
• client-key-data
• certificate-authority-data

확인:

kubectl config view --kubeconfig /etc/kubernetes/admin.conf --raw

---

6) 인증서가 “서로를 어떻게 막아주나”: 공격 시나리오로 이해하기

6.1 도청(스니핑)만 하는 해커

• TLS가 암호화하므로 패킷을 주워도 내용을 복호화하기 어렵습니다.
• 단, 키가 유출되면(예: 서버 개인키, 세션키, CA 키) 이야기가 달라집니다.

6.2 “가짜 서버”를 세워서 속이는 해커(MITM)

예: 해커가 kube-apiserver인 척, 또는 etcd인 척 서버를 세움

이때 TLS가 막는 구조는 다음입니다.

• 클라이언트는 서버가 제시한 인증서를 보고,
  • 그 인증서가 클러스터가 신뢰하는 CA로 서명됐는지 확인합니다.
• 그리고 서버는 핸드셰이크 과정에서 “이 인증서의 개인키를 내가 진짜 가지고 있다”를 서명으로 증명해야 합니다.
  • 인증서(공개키)만 복사한 공격자는 개인키가 없어서 이 단계에서 실패합니다.

즉 “가짜 서버 방지”는

1. CA 체인 검증(이 인증서가 우리 CA가 서명한 게 맞냐)
2. 개인키 소유 증명(서명 검증이 되냐)
   이 두 겹으로 막습니다.

6.3 최악: CA 개인키(ca.key) 유출

이 경우 공격자는:

• “클러스터가 신뢰하는 CA”로 직접 서명한 새로운 인증서를 만들어낼 수 있습니다.
• 즉, “진짜처럼 보이는 서버/클라이언트 신분증”을 발급할 수 있습니다.

그래서 실무에서 가장 중요한 방어는:

• CA 개인키 접근권한 최소화
• 파일 권한/소유자 엄격하게
• 가능하면 CA 키는 오프라인 보관/접근 통제(조직 규모가 크면 HSM/KMS 고려)
• 정기적인 만료/회전 계획

---

7) Kubernetes에서 “클라이언트 인증서”는 결국 RBAC과 연결된다 (중요 포인트)

Kubernetes는 일반 사용자 계정을 내부 DB에 만들지 않습니다. 대신,

• 인증서의 CN, O(그룹) 같은 필드를 기반으로 “누구인지”를 식별하고
• 그 다음은 RBAC으로 권한을 부여합니다.

예를 들어 관리자 인증서에 종종 이런 식으로 들어갑니다.

• CN: admin
• O: system:masters (강력한 관리자 그룹)

이런 식으로 “인증(너 누구야)”과 “인가(너 뭐 할 수 있어)”가 이어집니다.

---

8) 지금 단계에서 꼭 기억해야 하는 한 줄 요약

• Kubernetes TLS는 “암호화”만이 아니라 서버/클라이언트 신원 확인(mTLS) 이 핵심이다.
• API 서버 / etcd / kubelet은 서버 인증서가 필요하고, scheduler/controller/proxy/admin 등은 클라이언트 인증서가 필요하다.
• CA 개인키가 최상위 보안 자산이다.
• 확장자 규칙은 힌트일 뿐, 실무에선 openssl로 “파일 내용”을 확인하는 습관이 중요하다.