[Kubernetes] Kubernetes PKI

들어가며

Kubernetes 클러스터를 구축하다 보면 수많은 인증서 파일들을 마주하게 된다. /etc/kubernetes/pki/ 디렉토리에 ca.crt, apiserver.crt, etcd/server.crt 등 다양한 인증서들이 존재하는데, 왜 이렇게 많은 인증서가 필요한 것일까?

Kubernetes 공식 문서에 따르면, 아래와 같은 문구를 확인할 수 있다.

쿠버네티스는 TLS를 통한 인증을 위해서 PKI 인증서가 필요하다. 만약 kubeadm으로 쿠버네티스를 설치한다면, 클러스터에 필요한 인증서는 자동으로 생성된다. 또한 더 안전하게 자신이 소유한 인증서를 생성할 수 있다.

즉, Kubernetes는 컴포넌트 간 통신을 암호화하고 상호 인증하기 위해 PKI 인증서를 사용한다. kubeadm을 사용하면 인증서가 자동 생성되어 편리하지만, 보안 요구사항에 따라 직접 인증서를 생성하여 개인키를 API Server에 저장하지 않고 별도로 관리할 수도 있다.

아래 내용은 kubeadm으로 클러스터를 프로비저닝하는 방식을 기준으로 설명한다. kubeadm은 공식 문서에서 권장하는 방식이며 PKI 구조를 이해하기에 가장 직관적이다. k3s, RKE, 수동 설치 등 다른 도구를 쓰면 인증서·키의 경로나 파일명이 달라질 수 있지만, CA 개수와 역할, 서버·클라이언트 인증서의 쓰임 등 기본 PKI 구조는 도구와 관계없이 일맥상통한다.

개념

Kubernetes는 클러스터 내부의 모든 컴포넌트 간 통신을 보호하기 위해 자체 Certificate Authority(CA)를 운영하고, 이를 기반으로 각 컴포넌트에 필요한 인증서를 발급/관리한다.

Kubernetes PKI의 핵심 특징은 다음과 같다.

• 자체 Root CA를 생성한다.
• 모든 컴포넌트 인증서를 직접 발급/관리한다.
• 외부 CA에 의존하지 않는다.

참고: PKI

PKI 글에서 사설 PKI는 조직 내부에서 운영하는 독립적인 PKI 시스템이라고 설명했는데, Kubernetes의 클러스터 인증서 인프라가 바로 사설 PKI의 전형적인 구현 사례다.

자체 PKI 구축 이유

Kubernetes가 DigiCert나 Let’s Encrypt 같은 공개 CA를 사용하는 대신 자체 PKI를 구축하는 이유가 있다.

• 폐쇄망 운영 가능: 인터넷 연결 없이도 인증서를 발급할 수 있다. 보안이 중요한 환경에서 외부 네트워크에 의존하지 않고 독립적으로 운영할 수 있다.
• 완전한 통제 가능: 인증서의 만료 정책, 갱신 주기, 발급 규칙을 모두 자체적으로 결정할 수 있다. 공개 CA의 정책에 종속되지 않는다.
• 비용 절감: 클러스터 규모에 따라 수십~수백 개의 인증서가 필요한데, 이를 모두 상업 CA에서 구매하면 비용이 막대하다. 자체 PKI는 무료다.
• 보안 강화: 외부 CA의 개인키가 유출되어도 우리 클러스터에는 영향이 없다. 신뢰 체인이 완전히 독립적이다.

핵심 메커니즘: mTLS

Kubernetes 컴포넌트 간 통신은 mTLS(Mutual TLS)를 사용한다. 일반적인 TLS는 서버만 인증서를 제시하지만, mTLS는 클라이언트도 인증서를 제시하여 양방향으로 신원을 검증한다.

mTLS 필요성

일반적인 웹 서비스에서는 서버만 인증하면 충분하다. 하지만 Kubernetes 클러스터 내부에서는 모든 통신 당사자가 신뢰할 수 있는 컴포넌트인지 확인해야 한다. 악의적인 Pod가 API Server인 척 할 수도 있고, 공격자가 kubelet인 척 할 수도 있기 때문이다. mTLS는 통신하는 양쪽 모두가 정당한 컴포넌트임을 보장한다.

mTLS 인증 과정

1. Client → Server: ClientHello (지원하는 암호화 알고리즘 목록 전송)
2. Server → Client: ServerHello + 서버 인증서 전송
3. Client: 서버 인증서 검증
   • CA 인증서로 서버 인증서의 서명 검증
   • 서버 인증서의 유효 기간 확인
   • 서버 인증서의 CN(Common Name) 또는 SAN(Subject Alternative Name)이 접속 중인 서버와 일치하는지 확인
4. Client → Server: 클라이언트 인증서 전송
5. Server: 클라이언트 인증서 검증
   • CA 인증서로 클라이언트 인증서의 서명 검증
   • 클라이언트 인증서의 유효 기간 확인
   • 인증서의 Organization(O) 필드로 사용자의 그룹 확인
   • 인증서의 Common Name(CN) 필드로 사용자 이름 확인
6. 양측: 세션 키 교환 및 암호화 통신 시작

인증서가 많은 이유

앞서 본 것처럼 Kubernetes의 핵심인 mTLS 통신 메커니즘에서는 통신하는 양쪽 모두 인증서로 신원을 증명해야 한다. 그래서 컴포넌트와 통신 쌍이 많아질수록 필요한 인증서 수도 늘어난다. 그러니 이렇게 인증서가 많은 이유는 이해하고 보면 당연한 구조다.

사실 쿠버네티스만 특별히 인증서가 많은 것은 아니고, 복잡한 분산 시스템에서 높은 수준의 보안을 유지하기 위해서는 이렇게 많은 인증서가 필요하다. 같은 수준의 복잡도와 보안을 요구하는 일반 시스템도 비슷한 개수의 인증서가 필요하다.

통신 관계가 복잡하다

              [etcd]
                ↕
[kubelet] ←→ [API Server] ←→ [Controller Manager]
                ↕
         [Scheduler]  [kube-proxy]

각 화살표마다 양방향 인증이 필요하다. API Server와 etcd가 통신할 때, API Server는 클라이언트로서 apiserver-etcd-client.crt가 필요하고, etcd는 서버로서 etcd-server.crt가 필요하다. etcd는 “당신이 진짜 API Server인가?”를 클라이언트 인증서로 검증하고, API Server는 “당신이 진짜 etcd인가?”를 서버 인증서로 검증한다.

역할이 전환된다

API Server와 kubelet의 관계를 보자. API Server가 kubelet에 로그 조회나 exec 명령을 보낼 때는 API Server가 클라이언트이고 kubelet이 서버다. 반대로 kubelet이 노드 상태를 보고할 때는 kubelet이 클라이언트이고 API Server가 서버다. 같은 두 컴포넌트 사이에서도 역할에 따라 다른 인증서가 필요하다.

최소 권한 원칙

만약 하나의 인증서로 모든 일을 한다면 어떻게 될까? 하나가 유출되면 전체 시스템이 위험해진다. 어떤 컴포넌트가 어떤 권한을 가지는지 불분명해지고, 감사(audit)도 어려워진다.

역할별로 인증서를 분리하면 유출 시 피해를 최소화할 수 있다. apiserver-kubelet-client.crt가 유출되어도 kubelet 접근만 위험하고, etcd나 다른 컴포넌트는 안전하다. 다른 인증서를 즉시 폐기할 필요도 없다.

인증서 생성 방법

openssl을 이용한 일반적인 인증서 생성 방법이다. Kubernetes 전용이 아니라 PKI의 기본 흐름(CA 생성 → CSR → 서명)을 이해하는 데 도움이 된다.

CA 인증서 생성

클러스터당 최초 1회 생성한다.

# 1. CA 개인키 생성
openssl genrsa -out ca.key 2048

# 2. CA 자체 서명 인증서 생성 (CSR 없이 바로 생성)
openssl req -x509 -new -nodes -key ca.key \
  -subj "/CN=kubernetes-ca" \
  -days 3650 -out ca.crt

컴포넌트 인증서 생성

각 컴포넌트마다 자신을 인증하기 위한 인증서를 생성한다.

# 1. 컴포넌트 개인키 생성
openssl genrsa -out apiserver.key 2048

# 2. CSR 생성 (공개키는 이 과정에서 자동 포함됨)
openssl req -new -key apiserver.key \
  -subj "/CN=kube-apiserver" \
  -out apiserver.csr

# 3. CA로 인증서 서명/발급
openssl x509 -req -in apiserver.csr \
  -CA ca.crt -CAkey ca.key -CAcreateserial \
  -out apiserver.crt -days 365

PKI 구축

구축 방법

수동 생성

학습 목적이거나 특별한 요구사항이 있는 경우 모든 인증서를 직접 생성할 수 있다.

실제 Kubernetes 공식 문서도 아래와 같이 말한다.

필요한 인증서를 kubeadm으로 생성하기 싫다면, 단일 루트 CA를 이용하거나 모든 인증서를 제공하여 생성할 수 있다.

개념에서 본 것처럼 CA 인증서 생성 → 컴포넌트별 CSR 생성 → CA가 서명하는 방식으로 구축하면 되며, Kubernetes the Hard Way 문서가 이 방법을 상세히 설명한다. 실제 운영 환경에서는 권장되지 않지만, PKI 구조를 깊이 이해하는 데 도움이 된다.

해당 튜토리얼의 인증서 설정 파일 구조와 실제 생성 과정은 4.2. ca.conf 파일 분석과 4.3. 인증서 생성 및 배포 글에서 확인할 수 있다.

자동 생성

대부분의 클러스터 프로비저닝 도구는 필요한 PKI 인증서를 설치 시 자동으로 생성한다. 기본 PKI 구조는 동일하고, 도구마다 저장 경로·파일명·갱신 방법만 다를 수 있다.

kubeadm

Kubernetes 공식 문서에서 권장하는 방식이다. 클러스터 설치 시 필요한 모든 인증서가 자동으로 생성된다.

kubeadm init

kubeadm이 생성하는 인증서는 기본적으로 1년 후 만료된다. CA 인증서는 10년이다. 만료 전에 kubeadm certs renew 명령으로 갱신해야 하며, 갱신하지 않으면 클러스터 컴포넌트 간 통신이 실패한다.

기타 (K3s, RKE2 등)

K3s, RKE2, Kubespray 등 다른 프로비저닝 도구도 클러스터 설치 시 인증서를 자동 생성한다. CA 개수와 역할, 서버·클라이언트 인증서의 쓰임은 앞에서 본 구조와 같고, 인증서가 놓이는 디렉토리나 파일명, 갱신 절차는 각 도구 문서를 참고하면 된다.

실제 PKI 디렉토리 구조

아래는 kubeadm으로 설치한 클러스터 기준의 디렉토리 구조다. k3s·수동 설치 등 다른 방식에서는 경로와 파일명이 다를 수 있으나, 디렉토리 트리와 파일 역할은 이 글 앞에서 본 CA 구조·인증서 목록과 대응한다.

인증서 파일

kubeadm의 경우 인증서 파일은 /etc/kubernetes/pki/에 저장된다.

/etc/kubernetes/pki/
├── ca.crt, ca.key                        # 클러스터 CA
├── apiserver.crt, apiserver.key          # API Server
├── apiserver-kubelet-client.crt, .key    # API Server → kubelet 클라이언트
├── apiserver-etcd-client.crt, .key       # API Server → etcd 클라이언트
├── front-proxy-ca.crt, .key              # Aggregation Layer CA
├── front-proxy-client.crt, .key          # Aggregation Layer 클라이언트
├── etcd/
│   ├── ca.crt, ca.key                    # etcd CA (별도)
│   ├── server.crt, server.key            # etcd 서버
│   ├── peer.crt, peer.key                # etcd 피어 통신
│   └── healthcheck-client.crt, .key      # etcd 헬스체크
└── sa.key, sa.pub                        # ServiceAccount 토큰 서명용

kubeconfig 파일

위에서 살펴본 인증서들은 /etc/kubernetes/pki/에 파일로 존재하지만, 실제로 컴포넌트가 API Server에 인증할 때는 이 인증서를 직접 참조하는 것이 아니라 kubeconfig 파일을 통해 사용한다. kubeconfig는 클러스터 접속 정보(API Server 주소 등)와 함께 클라이언트 인증서를 포함하거나 참조하는 파일로, PKI 인증서의 배달 수단 역할을 한다. /etc/kubernetes/ 디렉토리에 인증서 파일(pki/)과 나란히 위치하는 것도 이 때문이다.

kubeconfig 파일 자체의 구조와 사용법에 대해서는 kubeconfig 개요 글에서 다룬다. 여기서는 PKI 관점에서 각 kubeconfig에 어떤 신원(identity)의 인증서가 포함되어 있는지를 살펴본다.

/etc/kubernetes/
├── admin.conf              # 클러스터 관리자용
├── kubelet.conf            # kubelet용
├── controller-manager.conf # controller-manager용
└── scheduler.conf          # scheduler용

각 kubeconfig에 포함된 인증서의 CN(Common Name)과 O(Organization) 필드는 다음과 같다.

파일명	기본 CN	O (그룹)	용도
admin.conf	kubernetes-admin	system:masters	클러스터 관리자
kubelet.conf	system:node:<nodeName>	system:nodes	각 노드의 kubelet
controller-manager.conf	system:kube-controller-manager	-	controller-manager
scheduler.conf	system:kube-scheduler	-	scheduler

kubelet.conf의 <nodeName>은 API Server에 등록된 노드 이름과 정확히 일치해야 한다.

인증서 상세 분석

앞 1장에서는 개념과 구축 흐름을 다뤘다. 이번 장에서는 Kubernetes PKI의 인증서를 역할·CA·컴포넌트·목록 관점에서 상세히 분석한다.

인증서의 역할

Kubernetes PKI에서 인증서는 세 가지 역할로 구분된다.

CA 인증서

클러스터의 최상위 신뢰 기관이다.

• 클러스터 생성 시 자체 서명된(self-signed) CA 인증서 생성
• 모든 컴포넌트 및 사용자 인증서에 서명
• CA의 개인키(private key)로 서명함으로써 해당 인증서의 신뢰성 보장

서버 인증서

서버가 자신이 정당한 서버임을 클라이언트에게 증명한다.

• API Server가 자신이 정당한 서버임을 클라이언트에게 증명
• CA에 의해 서명됨
• 클라이언트는 CA 인증서로 서버 인증서를 검증

클라이언트 인증서

사용자 또는 클러스터 컴포넌트의 신원을 증명한다.

• kubectl과 같은 클라이언트가 자신의 신원을 API Server에 증명
• CA에 의해 서명됨
• API Server는 CA 인증서로 클라이언트 인증서를 검증

CA 구조

Kubernetes PKI는 세 개의 독립적인 CA를 운영한다.

kubernetes-ca (클러스터 CA)
├── kube-apiserver
├── kube-apiserver-kubelet-client
├── kube-controller-manager
├── kube-scheduler
└── kubelet (각 노드별)

etcd-ca (etcd 전용 CA)
├── etcd-server
├── etcd-peer
└── etcd-healthcheck-client

front-proxy-ca (API 확장용 CA)
└── front-proxy-client

각 CA는 자신이 담당하는 영역의 인증서를 발급(서명)하고, 해당 영역의 컴포넌트들이 상대방 인증서를 검증할 때 사용된다.

kubernetes-ca (클러스터 CA)

클러스터의 핵심 컴포넌트들을 위한 범용 CA다.

역할	개인키/공개키	설명
발급	개인키	kube-apiserver, kube-apiserver-kubelet-client, kubelet 등 클러스터 컴포넌트 인증서에 서명. CA의 개인키(ca.key) 로 서명한다.
검증	공개키	클러스터 컴포넌트 간 통신 시 상대방 인증서 검증에 사용. CA 인증서(ca.crt) 로 서명을 검증한다.

예컨대, API Server가 Kubelet에 요청할 때 사용되는 흐름을 보자.

API Server
    ↓ [apiserver-kubelet-client.crt 제시 (kubernetes-ca가 서명한 인증서)]
Kubelet
    ↓ [kubernetes-ca.crt로 서명 검증]
"OK, 이건 정당한 API Server다" → 요청 처리

etcd-ca (etcd 전용 CA)

etcd 클러스터 전용 CA다. etcd는 클러스터의 모든 상태를 저장하는 핵심 데이터 저장소이므로, 별도 CA로 분리하여 강력한 보안 격리를 제공한다.

역할	개인키/공개키	설명
발급	개인키	etcd-server, etcd-peer, etcd-healthcheck-client 인증서에 서명. CA의 개인키(etcd/ca.key) 로 서명한다.
검증	공개키	etcd 클러스터 내부 통신 및 etcd 클라이언트 인증 시 사용. CA 인증서(etcd/ca.crt) 로 서명을 검증한다.

etcd CA를 별도로 분리하면, etcd CA가 손상되더라도 kubernetes-ca는 안전하게 유지된다. 반대도 마찬가지다.

참고: etcd 인증서 종류

• etcd-server: etcd가 클라이언트(API Server 등) 요청을 받을 때 서버 인증서로 사용
• etcd-peer: etcd 노드들끼리 클러스터 데이터를 동기화할 때 상호 인증에 사용
• etcd-healthcheck-client: kubelet이 etcd 헬스체크를 수행할 때 클라이언트 인증서로 사용
• apiserver-etcd-client: API Server가 etcd에 데이터를 읽고 쓸 때 클라이언트 인증서로 사용 (이 인증서도 etcd-ca가 서명)

front-proxy-ca (API 확장용 CA)

Kubernetes Aggregation Layer 전용 CA다. kube-apiserver가 확장 API 서버(metrics-server 등)에 요청을 프록시할 때 사용된다.

역할	개인키/공개키	설명
발급	개인키	front-proxy-client 인증서에 서명. CA의 개인키(front-proxy-ca.key) 로 서명한다.
검증	공개키	Extension API 서버가 kube-apiserver로부터 온 요청을 검증할 때 사용. CA 인증서(front-proxy-ca.crt) 로 서명을 검증한다.

front-proxy-ca를 별도로 분리하면, Extension API 서버가 손상되더라도 kubernetes-ca는 영향받지 않는다.

참고: Front Proxy 동작 방식

일반적인 Core API 요청(kubectl get pods)은 kube-apiserver가 직접 처리하고 etcd에서 데이터를 조회한다. 하지만 Aggregated API 요청(kubectl top nodes)은 Extension API 서버로 프록시된다.

이 때, Extension API 서버가 요청이 정당한 kube-apiserver로부터 온 것인지 확인하기 위해 인증서가 필요하다. 여기서 front-proxy-client용 인증서를 사용한다.

Client (kubectl)
    ↓
kube-apiserver (Front Proxy 역할)
    ↓ [front-proxy-client.crt 제시 (front-proxy-ca가 서명한 인증서)]
Extension API Server (metrics-server 등)
    ↓ [front-proxy-ca.crt로 서명 검증]
"OK, 정당한 kube-apiserver다" → 요청 처리

Extension API 서버 예시: metrics-server(kubectl top), custom-metrics-server(HPA), service-catalog, 사용자 정의 API 서버 등

컴포넌트 인증서: Server / Client / Kubelet

CA가 아니라 CA가 발급한 컴포넌트용 인증서를, 공식 문서(영문)처럼 Server / Client / Kubelet 세 가지 관점으로 정리한 것이다.

Server Certificates

• API server 엔드포인트용 서버 인증서
• etcd 서버용 서버 인증서
• 각 kubelet용 서버 인증서(노드마다 kubelet 1개)
• (선택) front-proxy용 서버 인증서

Client Certificates

• 각 kubelet용: API server에 Kubernetes API 클라이언트로 인증
• 각 API server용: etcd에 인증
• controller manager용: API server와 안전하게 통신
• scheduler용: API server와 안전하게 통신
• 각 노드의 kube-proxy용: API server에 인증
• (선택) 클러스터 관리자용: API server에 인증
• (선택) front-proxy용 클라이언트 인증서

Kubelet Certificates: Kubelet의 서버·클라이언트 인증서

API server가 kubelet과 안전하게 연결하고 자신을 인증하려면 클라이언트 인증서가 필요하다. 이때, 아래와 같은 방식이 있다.

1. apiserver용 인증서를 그대로 쓰는 방식(Shared)
2. 별도 클라이언트 인증서를 쓰는 방식(Separate)

kubeadm으로 클러스터를 프로비저닝해 인증서를 사용하는 경우, 2번 방식(Separate)을 사용하며, apiserver-kubelet-client.crt / apiserver-kubelet-client.key를 발급한다.

참고: front-proxy 인증서는 extension API server를 위한 aggregation layer를 쓸 때만 필요하다. etcd는 클라이언트·피어 모두에 대해 mutual TLS를 사용한다.

필수 인증서 목록

Kubernetes 클러스터에 필요한 인증서를 CA 인증서와 컴포넌트 인증서를 모두 포함해 정리한 목록이다. kubeadm으로 설치하면 대부분 /etc/kubernetes/pki에 저장된다. 공식 문서의 “모든 인증서” 표에는 각 인증서의 종류 컬럼이 있어, 해당 인증서가 서버 인증서로만 쓸 수 있는지, 클라이언트 인증서로만 쓸 수 있는지, 둘 다 가능한지 명시되어 있다.

인증서 종류 ( server / client / dual )

종류는 Extended Key Usage(EKU)와 용도에 따라 세 가지로 나뉜다.

• server 전용: 접속을 받기만 하는 엔드포인트용
  • EKU에 TLS Web Server Authentication만 포함
  • 예: API Server(apiserver.crt)
• client 전용: 한쪽 방향으로만 접속하는 컴포넌트용
  • EKU에 TLS Web Client Authentication만 포함
  • 예: API Server가 etcd나 kubelet에 접속할 때 쓰는 클라이언트 인증서
• server, client 둘 다 (dual): 통신에서 서버이자 클라이언트 역할을 동시에 하는 컴포넌트용
  • EKU에 TLS Web Server Authentication과 TLS Web Client Authentication이 둘 다 들어 있다.
  • 같은 인증서가 상황에 따라 서버 인증서로 쓰이기도 하고 클라이언트 인증서로 쓰이기도 함

dual 예: etcd server.crt

/etc/kubernetes/pki/etcd/server.crt는 dual이다. 동일한 인증서가 두 가지 방식으로 사용된다.

사용처	역할	설명
etcdctl → etcd	클라이언트 인증서	etcdctl이 --cert=server.crt, --key=server.key로 etcd에 접속할 때, etcd 서버가 “누구냐?” 하고 클라이언트 인증서를 검증(mTLS). 이때 server.crt는 클라이언트의 신원 증명이다.
apiserver → etcd	서버 인증서	etcd가 TLS 리스너에 server.crt, server.key를 바인딩해 두고, apiserver가 etcd에 접속하면 etcd가 이 인증서를 제시한다. apiserver는 CA(ca.crt)로 “이 etcd 서버가 진짜인가?” 검증한다. 이때 server.crt는 서버의 신원 증명이다.

etcd 노드 간 통신에 쓰는 etcd/peer.crt(kube-etcd-peer)도 dual이다. 피어 간에 서로가 서버이자 클라이언트가 되기 때문이다.

CA 인증서 (목록)

파일	기본 CN	용도
ca.crt, ca.key	kubernetes-ca	Kubernetes 일반 CA
etcd/ca.crt, etcd/ca.key	etcd-ca	etcd 전용 CA
front-proxy-ca.crt, front-proxy-ca.key	kubernetes-front-proxy-ca	API 확장용 CA

서버·클라이언트 인증서 (목록)

아래 표는 공식 문서 모든 인증서에 나온 인증서를 종류(server 전용 / client 전용 / server·client dual)와 함께 정리한 것이다. 부모 CA, SAN(호스트) 등 상세는 공식 표를 참고하자.

파일	기본 CN	부모 CA	종류	용도
apiserver.crt, .key	kube-apiserver	kubernetes-ca	server	API Server TLS
apiserver-kubelet-client.crt, .key	kube-apiserver-kubelet-client	kubernetes-ca	client	API Server → kubelet 호출
front-proxy-client.crt, .key	front-proxy-client	kubernetes-front-proxy-ca	client	API 확장 요청
etcd/server.crt, .key	kube-etcd	etcd-ca	server, client	etcd 서버
etcd/peer.crt, .key	kube-etcd-peer	etcd-ca	server, client	etcd 노드 간 통신
etcd/healthcheck-client.crt, .key	kube-etcd-healthcheck-client	etcd-ca	client	etcd 헬스체크
apiserver-etcd-client.crt, .key	kube-apiserver-etcd-client	etcd-ca	client	API Server → etcd 접근

ServiceAccount 키

파일	용도
sa.key	ServiceAccount 토큰 서명용 개인키
sa.pub	ServiceAccount 토큰 검증용 공개키

인증서와 명령어 파라미터

각 인증서는 컴포넌트 실행 시 명령어 파라미터로 지정된다. 예를 들어 kube-apiserver는 --tls-cert-file, --etcd-certfile, --kubelet-client-certificate 등의 파라미터로 어떤 인증서를 사용할지 지정받는다. 컴포넌트가 시작할 때 통신 상대방을 인증하고 자신을 증명하기 위해 어떤 인증서를 사용할지 알아야 하기 때문이다.

각 인증서가 어떤 명령어의 어떤 파라미터로 사용되는지에 대한 상세 매핑은 공식 문서의 인증서 파일 경로를 참고하자.

결론

Kubernetes PKI는 복잡해 보이지만, 결국 “누가 누구인지 확인하고, 통신을 암호화한다”는 PKI의 기본 원칙을 충실히 따른다. 인증서가 많은 이유는 컴포넌트가 많고, 각 컴포넌트가 서로 양방향 인증을 하며, 최소 권한 원칙을 따르기 때문이다.

자체 PKI를 구축함으로써 Kubernetes는 폐쇄망에서도 운영 가능하고, 완전한 통제가 가능하며, 비용을 절감하고, 외부 CA에 의존하지 않는 독립적인 보안 체계를 갖추게 된다. 처음에는 인증서 파일들이 복잡하게 느껴지겠지만, 각 인증서의 역할과 통신 흐름을 이해하면 클러스터 보안의 전체 그림이 보이기 시작한다.