[CKA] 41. Generate Certificates

Date

2025/01/13

Generate Certificates

아래 그림과 같은 인증서들을 가진다고 할 때, 인증서를 생성하기 위한 방법으로는 Easy-RSA, OpenSSL, CFSSL 등이 있다. OpenSSL을 사용하여 인증서를 생성하는 방법에 대해 알아보자.

CA Certificates Generation

인증서를 생성할 때는 우선 개인 키를 생성하고, 개인 키를 사용해 CSR을 생성해야 한다.

1) Private Key 생성

openssl genrsa -out ca.key 2048
Bash
복사

2) CSR 생성

생성된 개인 키를 사용하여 인증서 서명 요청을 생성한다. CSR은 모든 세부 정보가 포함된 인증서와 유사하지만 서명이 없는 파일이다. CSR에서는 인증서의 용도를 정의하기 위해 Common Name (CN) 필드에 구성 요소의 이름을 지정한다.

openssl req -new -key ca.key -subj "/CN=KUBERNETES-CA" -out ca.csr
Bash
복사

3) Sign Certificates

OpenSSL X509 명령을 사용해 CSR을 지정하여 인증서를 서명한다. CA 자체의 인증서이므로, 1단계에서 생성한 개인 키를 사용해 CA에 의해 자체 서명된다.

openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt
Bash
복사

다른 모든 인증서에 서명을 할 때, ca 키 페어를 사용해 서명한다.

Client Certificates Generation

인증서를 생성하는 방법은 기본적으로 동일하다.

1) Private Key 생성

openssl genrsa -out <client>.key 2048
Bash
복사

2) CSR 생성

openssl req -new -key ca.key -subj "/CN=<Common Name>" -out <client>.csr
Bash
복사

Admin User

CSR을 생성할 때 CN은 Admin user의 이름을 지정하는 곳이다. 이 이름은 kubectl 클라이언트가 인증하는 이름이므로, kubectl 명령어를 실행할 때 로그나 다른 곳에서 볼 수 있다. 따라서 적절한 이름을 제공하는 것이 중요하다.

User Account는 Admin User와 일반 User를 구분해야할 필요가 있다. 이를 구분하기 위해서는 인증서에 사용자에 대한 그룹 세부정보를 추가해야 한다. 쿠버네티스에는 관리 관한을 가진 System Masters라는 그룹이 존재하는데, 이를 CSR을 생성할 때 추가해야 한다. 그룹 세부정보는 OU 파라미터를 사용해 추가할 수 있으며, 서명이 완료되면 관리 권한을 가진 admin에 대한 인증서를 얻을 수 있다.

openssl req -new -key ca.key -subj "/CN=kube-admin/O=system:masters" -out admin.csr
Bash
복사

Scheduler, Controller-Manager

kube-scheduler, kube-controller-manager는 Controlplane의 시스템 구성 요소이다. 따라서 이들을 생성할 때는 system이라는 키워드를 prefix로 가져야 한다(이름 앞에 붙어야 한다).

openssl req -new -key ca.key -subj "/CN=system:kube-scheduler" -out scheduler.csr
openssl req -new -key ca.key -subj "/CN=system:kube-controller-manager" -out controller-manager.csr
Bash
복사

3) Sign Certificates

OpenSSL X509 명령을 사용해 서명된 인증서를 생성한다. 이때 CA 인증서와 CA 개인키를 지정한다. 생성했던 CA 키 페어를 지정함으로써 인증서에 서명을 할 수 있다.

openssl x509 -req -in <client>.csr -CA ca.key -CAkey ca.key -out <client>.crt
Bash
복사

Server Certificates Generation

클라이언트는 서버가 보낸 인증서를 검증한다. 그 반대의 경우도 마찬가지로 서버는 클라이언트가 보낸 인증서를 검증한다. 이때 서버와 클라이언트 모두 CA의 공개 인증서가 필요하다. 웹 애플리케이션일 경우, CA 인증서는 브라우저에 이미 설치되어 있었다.

쿠버네티스에서도 다양한 구성 요소가 서로를 검증하기 위해서는 모두 CA의 루트 인증서 사본이 필요하다. 따라서 서버나 클라이언트를 인증서로 구성할 때, CA 루트 인증서도 지정해야 한다.

ETCD Servers

인증서를 생성하는 절차는 위의 방식과 동일하다. ETCD 서버는 고가용성 환경에서 다중 서버에 걸쳐 클러스터로 배포될 수 있다. 이때는 클러스터 내 다른 멤버 간의 통신을 보안하려면 추가적으로 peer 인증서를 생성해야 한다.

인증서가 생성되면 ETCD 서버가 시작될 때 지정된다. etcd 서버에 대한 정의파일에는 etcd 서버 키와 인증서에 대한 옵션과 peer 인증서를 지정하기 위한 옵션이 제공된다. 또한 클라이언트가 유효한지를 검증하기 위한 CA Root Certificate가 필요하다.

Kube-API Server

kube-apiserver도 기존과 같이 인증서를 생성할 수 있다. 이때 CSR을 생성하는 부분의 구성이 기존과 다르다.

쿠버네티스의 모든 작업은 kube-apiserver를 거치기 때문에 정보가 필요하면 kube-apiserver를 확인해야 한다. 이로 인해 클러스터 내에서 API Server는 많은 이름과 별칭을 가진다. 별칭 이외에도 IP 주소를 사용하기도 한다.

•

kubenetes

•

kubernetes.default

•

kubernetes.default.svc

•

kubernetes.default.svc.cluster.local

이 모든 이름은 kube-apiserver에 대한 인증서에 반드시 존재해야 한다. 인증서에 이 이름들이 없을 시, 이런 이름들로 kube-apiserver를 참조하여 연결할 수 없다.

CSR 생성

openssl req -new -key ca.key -subj "/CN=kube-apiserver" -out apiserver.csr \
-config openssl.cnf
Bash
복사

[req]
req_extesions = v3_req
distinguished_name = req_distinguished_name
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation
subjectAltName = @alt_names
[alt_names]
DNS.1 = kubernetes
DNS.2 = kubernetes.default
DNS.3 = kubernetes.default.svc
DNS.4 = kubernetes.default.svc.cluster.local
IP.1 = 10.96.0.1
IP.2 = 172.17.0.87
YAML
복사

Service Configuration

kube-apiserver는 구성 요소로 먼저 ca-file이 전달되어야 한다. CA 인증서는 모든 구성 요소가 클라이언트를 확인하기 위해 필요한 필수 요소이다. 그 다음 API Server 인증서를 TLS 인증 옵션에 제공되어야 한다.

kube-apiserver는 etcd와 kubelet에 대한 클라이언트이므로, etcd와 kubelet과 통신하기 위한 클라이언트 인증서가 필요하다.

Kubelet

Server CERT

kubelet 서버는 HTTPS API 서버로 각 노드에서 실행되며 노드 관리에 대한 책임이 있다. kubelet에 대한 인증서, 키 페어는 각 노드에 대해 필요하다. 이 인증서들은 kubelet이라 명명하지 않고, 노드의 이름을 따서 이름 짓는다.

인증서가 생성되면 이를 kubelet 구성 파일에 사용한다. CA인증서를 지정하고, 각 노드에서 노드 자신에 대한 인증서와 키를 가져야 한다.

# kubelet-config.yaml (node01)

kind: KubeletConfiguration
apiVersion: kubelet.ocnfig.k8s.io/v1beta1
authntication:
	x509:
		clientCAFile: "/var/lib/kubernetes/ca.pem"
authorization:
	mode: Webhook
clusterDomain: "cluster.local"
clusterDNS:
	- "10.32.0.10"
podCIDR: "${POD_CIDR}"
resolvConf: "/run/systemd/resolve/resolv.conf"
runtimeRequestTimeout: "15m"
tlsCertFile: "/var/lib/kubelet/kubelet-node01.crt"         # node 마다 변경
tlsPrivateKeyFile: "/var/lib/kubelet/kubelet-node01.key"   # node 마다 변경
YAML
복사

Client CERT

kubelet은 서버뿐만 아니라 kube-apiserver와 통신하는 클라이언트로써도 인증서를 가져야 한다. 노드는 kube-scheduler나 controller-manager와 같은 시스템 구성 요소이므로, system 키워드를 prefix로 가지며 node 키워드를 함께 갖는다. system:node:<node-name>

추가로 API Server로부터 올바른 사용 권한을 얻기 위해 Admin User와 같이 그룹을 가져야 한다.

openssl req -new -key ca.key \
 -subj "/CN=system:node:node01/O=system:nodes" \
 -out node01.csr
Bash
복사

인증서가 생성되면 마찬가지로 kube-config 파일에서 설정들이 사용된다.