개요
Kubernetes 클러스터를 운영하다 보면 다양한 보안 구성 요소들이 작동하는 것을 확인할 수 있습니다. 특히, 클러스터 내부의 모든 구성 요소들은 서로 TLS 인증서를 기반으로 통신하며, 이 인증서들은 일정한 주기로 교체되어야 합니다.
하지만 인증서의 유효 기간이 다가오는 것을 모르고 방치하거나, 갱신 과정을 잘못 수행하면 kubelet이 클러스터에 연결되지 않거나, kubectl 명령어가 동작하지 않는 문제가 발생할 수 있습니다. 이런 문제를 방지하기 위해, Kubernetes에서 인증서가 어떻게 생성되고 언제, 어떤 방식으로 교체되는지를 이해하는 것은 매우 중요합니다.
이 글에서는 Kubernetes의 인증서 구조부터 시작하여, 자동으로 갱신되는 인증서와 수동으로 갱신해야 하는 인증서의 차이, 인증서 갱신 명령어, 실습 예제까지 자세히 알아보겠습니다.
Kubernetes에서 인증서가 사용되는 곳
Kubernetes는 클러스터 내 모든 통신을 TLS로 암호화하여 보안을 강화합니다. 대표적으로 아래와 같은 컴포넌트 간 통신에서 인증서가 사용됩니다.
- kube-apiserver ↔ kube-controller-manager / kube-scheduler / etcd
- kubelet ↔ kube-apiserver
- kubectl ↔ kube-apiserver
- webhook admission controller ↔ kube-apiserver
이러한 통신에서 각 컴포넌트는 서버 인증서와 클라이언트 인증서를 사용하여 신뢰를 검증하고 통신을 허용합니다.
예를 들어 kubectl이 kube-apiserver에 접근할 때는 클라이언트 인증서를 이용하여 신원을 증명하며, 반대로 apiserver는 서버 인증서로 자신을 증명합니다.
Kubernetes 인증서 구조 이해하기
Kubernetes에서 인증서를 생성하고 저장하는 기본 경로는 다음과 같습니다.
/etc/kubernetes/pki
이 경로에는 여러 인증서와 프라이빗 키들이 존재하며, 주요 파일은 다음과 같습니다.
파일명 | 설명 |
ca.crt / ca.key | 클러스터의 Root CA 인증서와 키 |
apiserver.crt / apiserver.key | kube-apiserver용 서버 인증서 |
apiserver-kubelet-client.crt | kube-apiserver가 kubelet에 접근할 때 사용하는 인증서 |
front-proxy-ca.crt / front-proxy-client.crt | Aggregation layer용 인증서 |
etcd/server.crt / etcd/peer.crt 등 | etcd 서버 간 통신용 인증서 |
Kubernetes를 kubeadm으로 설치할 경우, 이러한 인증서들은 kubeadm init 명령어 실행 시 자동으로 생성되며, 기본적으로 1년의 유효 기간을 갖습니다.
인증서 갱신의 원리
인증서가 만료되면 Kubernetes 컴포넌트 간 통신에 문제가 생기므로, 사전에 갱신이 필요합니다. Kubernetes에서는 일부 인증서는 자동으로 갱신되고, 일부는 관리자가 수동으로 갱신해야 합니다.
자동으로 갱신되는 인증서
- kubelet client 인증서는 자동 갱신됩니다.
- kubelet에 --rotate-certificates=true 설정이 되어 있으면, kubelet은 유효 기간이 80% 경과한 시점부터 새로운 인증서를 요청하고 갱신합니다.
- 인증서 갱신 요청은 kubelet이 kube-apiserver에 요청하고, certificates.k8s.io API를 통해 처리됩니다.
- 해당 인증서는 보통 다음 위치에 저장됩니다:
/var/lib/kubelet/pki/kubelet-client-current.pem
수동으로 갱신해야 하는 인증서
아래 인증서들은 kubeadm을 사용하는 클러스터에서 수동으로 갱신해야 합니다.
- apiserver.crt
- apiserver-kubelet-client.crt
- front-proxy-client.crt
- etcd 관련 인증서 등
갱신은 kubeadm 명령어를 사용하여 수행할 수 있습니다.
kubeadm certs renew all
systemctl restart kubelet
갱신 전 인증서의 유효 기간을 확인하려면 아래 명령어를 사용할 수 있습니다.
kubeadm certs check-expiration
인증서 유효 기간과 교체 타이밍
Kubernetes 클러스터의 인증서는 대부분 유효 기간이 존재하며, 이 기간이 지나면 더 이상 해당 인증서를 사용할 수 없게 됩니다. 인증서가 만료되면 API 서버 접근 실패, 노드 등록 해제, etcd 통신 실패 등 다양한 문제가 발생할 수 있으므로, 사전에 주기적인 확인과 갱신 작업이 필요합니다.
자동 교체 타이밍 (kubelet)
Kubernetes에서 자동으로 인증서를 갱신하는 대표적인 컴포넌트는 kubelet입니다.
- kubelet은 기본적으로 인증서 유효 기간이 50% 경과했을 때 갱신을 시도합니다.
- 실제 갱신은 유효 기간의 80%가 경과한 시점에서 수행됩니다.
- 예를 들어 1년짜리 인증서라면, 약 292일(365일 × 0.8) 경과 시점에서 자동 갱신이 발생합니다.
- kubelet 로그에서 갱신 관련 메시지를 확인할 수 있습니다:
journalctl -u kubelet | grep certificate
certificate rotation is enabled
rotated certificate successfully
수동 인증서의 갱신 시기 판단
Control Plane의 인증서는 자동 갱신되지 않기 때문에, 관리자가 직접 유효 기간을 확인하고 갱신 시점을 결정해야 합니다.
이를 위해 kubeadm은 편리한 점검 명령어를 제공합니다.
kubeadm certs check-expiration
예시 출력:
CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY
admin.conf Mar 29, 2025 14:30 UTC 300d ca
apiserver Mar 29, 2025 14:32 UTC 300d ca
etcd/peer Mar 29, 2025 14:34 UTC 300d etcd-ca
인증서 교체를 정기적으로 점검하는 팁
- 월간 또는 분기별로 kubeadm certs check-expiration 결과를 CI/CD 또는 CronJob으로 점검
- 만료까지 30일 미만인 경우 슬랙/메일 등으로 알림 전송
- 기업 환경에서는 Ansible, Terraform 등 IaC 도구와 통합하여 자동화 가능
cert-manager를 이용한 인증서 자동화
앞서 설명한 kubeadm certs renew 방식은 수동으로 인증서를 갱신해야 한다는 단점이 있습니다. 클러스터 규모가 커지거나 다양한 어플리케이션이 TLS 인증서를 사용하는 경우, 인증서를 자동으로 발급하고 주기적으로 갱신해주는 시스템이 필요합니다.
이때 사용되는 대표적인 도구가 바로 cert-manager입니다.
cert-manager란?
cert-manager
Cloud native X.509 certificate management for Kubernetes and OpenShift
cert-manager.io
cert-manager는 Kubernetes 상에서 X.509 인증서 및 인증서 발급자를 관리하는 컨트롤러입니다. 다음과 같은 기능을 제공합니다.
- ACME (예: Let's Encrypt)를 통한 무료 TLS 인증서 발급
- CA 서버 또는 내부 Root CA를 통한 인증서 발급
- Kubernetes 리소스로 인증서를 선언적(Declarative)으로 관리
- 자동 갱신 (예: 30일 전 자동 갱신)
- webhook, ingress, gateway 등 다양한 리소스에 자동 연결
cert-manager 구조
cert-manager는 아래와 같은 구성 요소로 이루어져 있습니다.
구성 요소 | 설명 |
Issuer / ClusterIssuer | 인증서를 발급해줄 주체를 정의 (ACME, SelfSigned, CA 등) |
Certificate | 발급할 인증서의 정의 (common name, duration 등) |
CertificateRequest | 실제 인증서 발급 요청 (자동 생성됨) |
Secret | 발급된 인증서와 키가 저장되는 Kubernetes Secret |
cert-manager 설치 방법
cert-manager는 Helm 또는 YAML 매니페스트로 설치할 수 있습니다. 가장 간단한 설치 방법은 다음과 같습니다.
# CRDs 먼저 설치
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.17.1/cert-manager.crds.yaml
# cert-manager 설치
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager \
--namespace cert-manager \
--create-namespace \
--version v1.17.1
설치 후 아래 리소스를 확인합니다:
kubectl get pods -n cert-manager
사용 예시 1: SelfSigned 인증서 자동 발급
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: selfsigned-issuer
spec:
selfSigned: {}
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: example-cert
namespace: default
spec:
secretName: example-tls
duration: 90d
renewBefore: 15d
issuerRef:
name: selfsigned-issuer
kind: ClusterIssuer
commonName: example.default.svc.cluster.local
dnsNames:
- example.default.svc.cluster.local
위와 같이 선언하면 cert-manager가 자동으로 인증서를 생성하고, /etc/ssl/certs 대신 Kubernetes Secret에 저장합니다. 서비스나 Ingress, Gateway 등에서 쉽게 참조할 수 있습니다.
사용 예시 2: Let's Encrypt를 활용한 HTTPS Ingress 자동화
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: your-email@example.com
privateKeySecretRef:
name: letsencrypt-prod-key
solvers:
- http01:
ingress:
class: nginx
이후 Ingress 리소스에 다음과 같이 주석을 달면 cert-manager가 HTTPS 인증서를 자동으로 발급합니다.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-app
annotations:
cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
tls:
- hosts:
- myapp.example.com
secretName: myapp-tls
rules:
- host: myapp.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: my-app-svc
port:
number: 80
cert-manager의 자동 갱신 원리
cert-manager는 Certificate 리소스의 renewBefore 필드에 따라, 인증서 만료 시점보다 앞서 자동으로 재발급을 시도합니다. 기본값은 30일 전, 설정에 따라 조절 가능합니다.
또한, 문제가 발생하면 CertificateRequest, Events, Conditions 필드를 통해 상세한 원인 분석이 가능합니다.
kubectl describe certificate example-cert
kubectl describe certificaterequest -n default
정리
Kubernetes는 자체적으로 다양한 인증서 기반 보안 체계를 가지고 있으며, 이 인증서들은 클러스터의 신뢰성과 보안성 유지에 핵심적인 역할을 합니다. 운영 환경에서 인증서 만료는 심각한 장애를 유발할 수 있습니다. API 서버가 응답하지 않거나, 노드가 분리되거나, 서비스 간 통신이 실패하는 일이 발생할 수 있기 때문입니다. 이러한 리스크를 사전에 방지하려면 정기적인 인증서 관리 체계가 반드시 필요합니다.
또한 cert-manager와 같은 도구를 도입하면, 운영자의 수고를 줄이고 보안성을 자동으로 유지할 수 있는 기반을 마련할 수 있습니다.
운영 환경에서 발생하는 인증서 관리는 아주 중요한 역할을 하고있습니다. 본 글에서 다룬 내용들이 실무 운영대응에도 도움이 되셨으면 좋겠습니다.
'Kubernetes' 카테고리의 다른 글
Kubernetes는 어떻게 업그레이드가 진행되나요? (0) | 2025.04.06 |
---|---|
Pod의 OOMKilled 문제 원인 분석 및 해결 방법 (0) | 2025.03.03 |
Node가 Not Ready 상태일 때의 원인과 해결 방법 (0) | 2025.03.03 |
Pod가 Pending 상태일 때의 원인과 해결 방법 (0) | 2025.03.02 |
CrashLoopBackOff 원인 분석 및 해결 방법 (0) | 2025.03.01 |