🧠 TLS에서 공개키/개인키의 정확한 사용 방식

🔐 서버 인증 과정에서의 공개키 사용

1). 서버의 공개키는 TLS 인증서에 포함되어 브라우저로 전달됨

2). 브라우저는 이 공개키를 사용하여 '비밀정보(세션 키 등)'를 암호화함

3). 서버는 자신의 '개인키'로 복호화하여 그 비밀정보를 읽음

📌 이 과정은 브라우저 → 서버 방향의 데이터 전송에서만 비대칭키를 씀
(속도 문제 때문에 이후 통신은 대칭키로 전환)

🔐 공개키와 개인키의 역할 이해하기

이해를 돕기 위해 CA와 서버가 각각 키 쌍(Public/Private key)을 가지고 있다고 생각해보자.

🔑 서버 키쌍:

• 서버 공개키 (public key): 인증서에 포함되어 브라우저에 전달됨

• 서버 개인키 (private key): 서버가 비밀로 보관, 클라이언트는 접근 불가

🏢 CA 키쌍:

• CA 공개키: 브라우저와 OS에 미리 설치됨

• CA 개인키: 인증서에 디지털 서명할 때 사용됨 (절대 노출되지 않음)

🚫 클라이언트는 "자신의 개인키"로 암호화하지 않음

• TLS 클라이언트(브라우저)는 일반적으로 공개키를 받은 후, 대칭키(Pre-Master Secret)를 서버의 공개키로 암호화함

• 개인키로 암호화해서 보낸다는 개념은 TLS에서 사용되지 않음

📌 "암호화는 공개키, 복호화는 개인키"
👉 보안의 핵심은 '비밀을 가진 쪽만 읽을 수 있게 만드는 것'

📂 인증서 파일 이름 정리 팁

이 강의에서는 다양한 인증서 파일들이 등장합니다. 헷갈리지 않도록 다음 규칙을 기억하세요:

• 공개키 인증서 파일은 보통 .crt 또는 .pem 확장자를 사용
  예: server.crt, client.pem

• 개인키 파일은 .key 확장자 또는 이름에 -key가 포함됨
  예: server.key, server-key.pem

즉, key라는 단어가 있으면 개인키 파일, 없으면 공개키(인증서) 파일이라고 생각하면 된다.

☸️ 쿠버네티스에서 TLS 인증서의 사용

쿠버네티스 클러스터는 마스터 노드와 워커 노드로 구성되어 있으며,
모든 구성 요소 간 통신은 암호화되어야 하며, TLS로 보안되어야 합니다.

예시:

• 관리자가 kubectl을 통해 클러스터와 상호작용할 때
• API 서버가 클러스터 구성 요소들과 통신할 때

모든 통신은 TLS를 통해 보호되어야 하며,
따라서 다음과 같은 두 가지 조건이 충족되어야 합니다:

1. 각 서버 구성 요소는 서버 인증서를 사용해 클라이언트와 통신
2. 각 클라이언트 구성 요소는 클라이언트 인증서를 사용해 서버에 본인 인증

🧑‍💻 클라이언트 역할을 하는 구성 요소

1. 관리자(admin)

• kubectl을 통해 apiserver에 접속
• 인증서: admin.crt, 개인키: admin.key

2. kube-scheduler

• 파드 스케줄링을 위해 apiserver와 통신
• 인증서: scheduler.crt, 개인키: scheduler.key

3. kube-controller-manager

• 컨트롤 루프를 실행하며 apiserver와 통신
• 인증서: controller.crt, 개인키: controller.key

4. kube-proxy

• 각 노드에서 실행되며 apiserver와 통신
• 인증서: kubeproxy.crt, 개인키: kubeproxy.key

🔄 서버-서버 간 통신

• kube-apiserver는 클러스터 내 여러 서버와 통신 (etcd와 통신하는 유일한 서버):
  • etcd와 통신 시, etcd의 클라이언트 역할 → 인증 필요
  • kubelet과 통신 시에도 클라이언트 역할 → 인증 필요
• 이때 apiserver.crt와 apiserver.key를 재사용하거나, 별도 인증서를 생성해도 된다

🧱 구성요소별 인증서 그룹

유형	                      구성 요소         	                인증서 예시



서버 인증서	    kube-apiserver, etcd, kubelet	         *.crt, *.key
클라이언트 인증서	admin, scheduler, controller, proxy	     *.crt, *.key

🏛️ 인증서 발급을 위한 CA

• 모든 인증서는 하나 이상의 인증 기관(CA)에 의해 서명되야 함

• 쿠버네티스 클러스터에는 최소 하나의 CA가 필요

• 경우에 따라 etcd 전용 CA를 분리 가능
  예:

• 클러스터 공통 CA → ca.crt, ca.key

• etcd 전용 CA → etcd-ca.crt, etcd-ca.key
  예제 에서는 하나의 공통 CA만 사용

✅ 정리

• 쿠버네티스는 모든 통신을 TLS로 보호
• 서버 구성 요소는 서버 인증서로 신원 인증
• 클라이언트 구성 요소는 클라이언트 인증서로 접근 인증
• 모든 인증서는 CA에 의해 서명
• 인증서 이름은 .crt, 키는 .key로 구분

👉🏻 이미지 출처 : kodekloud.com