쿠버네티스 인증서

클라우드나 쿠버네티스 사용하다보면 인증서를 계속 마주칩니다.
한번은 정리하고 간다고 생각중에
좋을 글을 마주쳐서 읽어보면서 이번 기회에 정리해보려고합니다.

 

참조글

원문을 읽어보시길 추천드립니다. 

 

https://velog.io/@bytebliss/k8sdeploy-04

[K8S Deploy] Kubernets the Hard Way -04 - Provisioning a CA and Generating TLS Certificates & 인증 관련 개념 정리

https://zerotay-blog.vercel.app/6.PUBLISHED/AEWS%203%EA%B8%B0%20-%20EKS%20Workshop/6W%20-%20PKI%20%EA%B5%AC%EC%A1%B0,%20CSR%20%EB%A6%AC%EC%86%8C%EC%8A%A4%EB%A5%BC%20%ED%86%B5%ED%95%9C%20api%20%EC%84%9C%EB%B2%84%20%EC%A1%B0%ED%9A%8C/

6W - PKI 구조, CSR 리소스를 통한 api 서버 조회

 

 

 

쿠버네티스 인증

쿠버네티스 컴포넌트들은 API 서버를 기준으로 통신합니다. (컨트롤플레인 통신시)

해당 구간 통신은 기본적으로 TLS(HTTPS) 통신이 이루어집니다.

https://dreamlab.net/de/blog/post/kubernetes-api-authentication-using-tls-certificates-1/

 

TLS에서 중요한건 통신 암호화만큼 중요한 건 신원확인입니다.

그러한 신원확인을 돕는 도구가 인증서이고, 인증서를 신뢰하는 체계가 PKI 입니다.

 

PKI (Public Key Infrastructure)

PKI는 이름 그대로 공개키 기반 구조 시스템입니다.

 

용어

간략하게 정리하겠습니다.

 

해시 함수

임의 길이의 입력값을 고정 길이 출력으로 바꾸어 주는 함수입니다

해시 함수의 출력값을 해시값 또는 메시지 다이제스트라고 합니다.

 

https://m.upbitcare.com/academy/advice/52

 

해시함수는 입력이 하나만 달라져도 (안녕하세요->안녕하세여) 출력이 크게 바뀝니다.

또한 해시값에서 원문 복구는 매우 어렵습니다.

 

하지만, 같은입력은 같은 출력이 나오는 점에서 착안해서

데이터가 무결성(변조여부) 확인하는데 사용됩니다.

-> 입력값은 알지 못해도 두 출력값을 보고 두 입력값이 같은지 확인 가능합니다

 

 

 

 

대칭키 (Symmetric Key Algorithm)

암호화와 복호화에 쓰이는 키가 같습니다.

연산이 적어 빠르므로 안전이 보장된다면 데이터는 대칭키로 주고 받습니다.

-> TLS 통신에서 데이터 암호화는 대칭키로 진행됩니다.

 

비대칭키 (Asymmetric Key Algorithm)

비대칭키(공개키 암호)는 암호화와 서명 두가지 용도로 사용됩니다.
• 암호화: 공개키로 암호화 → 개인키로 복호화
• 서명: 개인키로 서명 → 공개키로 검증
TLS에서는 핸드셰이크에서 주로 서명(신원 확인) 과 키교환(ECDHE) 에 비대칭 기법이 쓰이고

실제 데이터 암호화는 대칭키로 진행합니다.

 

 

 

비대칭키에서 공개키는 말그대로 공개되어있습니다.

TLS 통신은 초반 핸드셰이크에서 비대칭키(서명/키교환)로 신원을 확인하고 이후 실제 트래픽은 대칭키로 암호화합니다.

 

하지만, 공개키가 진짜 상대의 공개키인지 어떻게 믿을 수 있을까요?

공개키 자체가 위조되거나 바꿔치기 된다면 비대칭키 방식은 무력해집니다.

요런느낌

 

 

그래서 필요한게 CA와 PKI 방식입니다.

이 공개키는 서버의 것이라고 제3자(인증기관)이 서명으로 보증해주고

클라이언트는 그 인증기관을 신뢰하는 것으로 공개키의 소유자를 확인해서 신뢰할 수 있습니다.

 

 

CA (Certificate Authority)

CA는 인증서를 발급(서명)하는 기관/시스템입니다.

쉽게 말해 이 공개키는 이 주체(도메인/조직)의 것이다라고 서명으로 보증해줍니다.

 

Root CA(루트 인증기관)

• 신뢰 체인의 최상단.
• 자기 자신을 self-signed 한 루트 인증서(root ca cert)를 가집니다.
• 이 루트 인증서의 공개키가 클라이언트의 신뢰의 출발점이 출발점입니다.
• Intermediate CA (중간 인증기관) 도 있습니다.

브라우저/OS에는 신뢰할 루트 CA 인증서들 (=루트CA의 공개키가 들어있는 인증서) 이 내장되어 있습니다.

 

 

X.509 인증서

공개키 + 주체 정보(CN/SAN 등) + CA 서명

 

 

신뢰체인

클라이언트 (ex.kubelet)가 내가 신뢰하는 CA를 기준으로 서버인증서를 검증

서버 인증서는 중간 CA가 보증하고, 
중간 CA는 루트 CA가 보증하며, 
클라이언트는 서버(leaf) 인증서부터 시작해 중간 CA들을 따라 루트 CA까지 체인을 올라가며 검증합니다.
마지막 루트 CA는 로컬 신뢰 저장소(trust store)에 이미 들어있습니다.

 

 

CA는 서버의 공개키가 들어있는 인증서(X.509)에 서명해주고

클라이언트는 OS/브라우저에 내장된 신뢰루트 CA를 검증해서 공개키를 믿고

이 검증이 이루어지는 구조가 Chain of Trust (신뢰체인) 입니다.

 

좀더 CA 과정을 보면서 이해해 보겠습니다.

 

 

 

 

CA 과정

Ingress 서버나 퍼블릭 클라우드 L7 로드밸런서에 적용할 인증서를 생성한다고 가정해보겠습니다.

참고)
쿠버네티스 내부 컴포넌트들은 보통 kubeconfig나 pki의 ca.crt로 클러스터 CA를 신뢰합니다.
istio, cilium도 mTLS를 위해 자체 CA를 사용합니다

 

 

1. 서버가 개인키를 생성합니다.

공개키는 보통 CSR/인증서안에 들어가게 됩니다

openssl genrsa -out server.key 2048

 

2. CSR(Certificate Signing Request) 생성

인증서서명요청 을 생성합니다.

SSL/TLS 인증서를 발급받기 위해 인증 기관(CA)에 제출하는 암호화된 텍스트 파일입니다.

CA에 보내는건 server.csr 입니다.

SAN에 도메인을 정확히 넣어줘야 인증서 매칭에 성공합니다.

요즘 TLS 검증은 CN보다 SAN을 우선
접속한 hostname/IP가 SAN에 없으면 다른 서버로 판단돼 핸드셰이크가 실패

 

# SAN : -addext "subjectAltName=
openssl req -new -sha256 \
  -key server.key -out server.csr \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

 

3. Self-Signed (자체서명)이 아니라 정식 CA 발급받는다면,

- ACME 로 자동발급 : Let's Encrypt 등

certbot과 같은 ACME 클라이언트가 키생성 + CSR + 도메인소유증명 + 발급 + 갱신을 자동으로 합니다.

(다음에 실습해보겠습니다)

쿠버네티스 컨트롤러에는 cert-manager가 있습니다.

 

- 상용 CA(유료) 수동발급

CA 포털에서 CSR을 업로드합니다.

 

4. 발급 받은 인증서를 서버에 설치

• server.key : 내 개인키
• fullchain.pem : 서버 인증서 + 중간CA 체인 묶음

 

CA의 서명 -> 클라이언트는 서버 공개키를 신뢰할 수 있고 TLS가 성립합니다.

그럼 쿠버네티스 인증서에는 어떤 것들이 있을까요?

 

 

쿠버네티스 인증서

 

수많은 인증서들

 

 

https://velog.io/@bytebliss/k8sdeploy-04

[K8S Deploy] Kubernets the Hard Way -04 - Provisioning a CA and Generating TLS Certificates & 인증 관련 개념 정리

표는 위 글에서 가져왔습니다

 

쿠버네티스는 TLS 기반으로 서버/클라이언트 모두 인증서로 통신합니다

항목	개인키	CSR인증서	인증서	참고 정보 (DN / SAN)	Extended Key Usage
Root CA	ca.key	X	ca.crt	CN = CA	-
admin	admin.key	admin.csr	admin.crt	CN = admin, O = system:masters	TLS Web Client Authentication
node-0	node-0.key	node-0.csr	node-0.crt	CN = system:node:node-0, O = system:nodes	TLS Web Server / Client Authentication
node-1	node-1.key	node-1.csr	node-1.crt	CN = system:node:node-1, O = system:nodes	TLS Web Server / Client Authentication
kube-proxy	kube-proxy.key	kube-proxy.csr	kube-proxy.crt	CN = system:kube-proxy, O = system:node-proxier	TLS Web Server / Client Authentication
kube-scheduler	kube-scheduler.key	kube-scheduler.csr	kube-scheduler.crt	CN = system:kube-scheduler, O = system:kube-scheduler	TLS Web Server / Client Authentication
kube-controller-manager	kube-controller-manager.key	kube-controller-manager.csr	kube-controller-manager.crt	CN = system:kube-controller-manager, O = system:kube-controller-manager	TLS Web Server / Client Authentication
kube-api-server	kube-api-server.key	kube-api-server.csr	kube-api-server.crt	CN = kubernetes, SAN: IP(127.0.0.1, 10.233.0.1), DNS(kubernetes,..)	TLS Web Server / Client Authentication
service-accounts	service-accounts.key	service-accounts.csr	service-accounts.crt	CN = service-accounts	TLS Web Client Authentication

 

Root CA

 

클러스터의 내부 PKI의 최상위 도장으로

ca.key(개인키)를 가지고 다른 인증서(CSR)에 서명합니다.

 

admin

kubectl 관리자

API server에 접근할 때 admin 을 증명하는 클라이언트 인증서입니다.

 

node-0 / node-1

kubelet (노드에이전트) 인증서

아래 상황에 따라 서버/클라이언트 둘 다 됩니다.

• (클라이언트) kubelet → apiserver에 상태 보고/리소스 조회
• (서버) apiserver → kubelet(10250)로 exec/log 등 접근

kube-api-server

kube-apiserver가 사용

api server는 여러주소로 접근됩니다.

- kubernetes.default.svc 와 같은 DNS

- 10.233.0.1

과 같은 kubernetes ClusterIP 

따라서 TLS 검증은 host/IP가 인증서 SAN에 있어야 통과됩니다.

 

 

 

 

참고1) API-server SAN 확인해보기

이미지에서 보이듯이 쿠버네티스는 ClusterIP로 10.233.0.1 로 있습니다.

파드 내에서 nslookup을 하면 kubernetes.default.svc 와 10.233.0.1을 바라보고있습니다.

 

openssl 명령어로 쿠버네티스 api-server에 적용된 인증서의 SAN을 확인하면 해당값들이 포함된 것을 확인할 수 있습니다.

 

 

 

참고2) 클러스터 인증서 만료기간 구경하기

퍼블릭클라우드는 마스터를 관리해주지만

클러스터를 kubeadm 같은 툴로 수동배포했다면 인증서 갱신을 관리 해주어야합니다.

 

기본설치 시 인증서 만료기간은 CA는 10년, Non-CA(leaf) 인증서는 1년입니다.

https://kubernetes.io/docs/reference/config-api/kubeadm-config.v1beta4/?utm_source=chatgpt.com

kubeadm Configuration (v1beta4)

 

컨트롤노드에서 언제 만료되는지 확인이 가능합니다.

sudo kubeadm certs check-expiration

leaf 인증서 -> 그냥 10년으로 배포했습니다.

 

leaf 인증서 갱신 명령어는 아래와 같습니다. (CA갱신x)

sudo kubeadm certs renew all
또는
sudo kubeadm certs renew apiserver
sudo kubeadm certs renew apiserver-kubelet-client
sudo kubeadm certs renew front-proxy-client
sudo kubeadm certs renew admin.conf
sudo kubeadm certs renew controller-manager.conf
sudo kubeadm certs renew scheduler.conf

 

갱신 후에는 apiserver/컨트롤 플레인 프로세스를 재시작 해주어야합니다.

sudo systemctl restart kubelet

 

kubelet 재기동시 kubeadm 기본(static pod) 구성에서는

kubelet이 apiserver/controller/scheduler를 다시 띄우면서 새 cert를 물고 올라옵니다.

 

 

 

그래서..

정리하면, PKI는 공개키를 믿게 만드는 구조이고

TLS는 그 신뢰를 기반으로 안전한 채널을 만듭니다.

TLS Handshake 단계에서 사용됩니다.

TLS 통신 관련해서는 다음에 정리해보겠습니다.