90DaysOfDevOps (Day 39)

고태규·2025년 11월 16일

devops

DevOps

목록 보기

38/50

해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.

Day 39 - Is TLS in Kubernetes really that hard to understand?

1. Kube API Server

쿠버네티스 클러스터의 보안을 논하기 전에, 클러스터가 상주하는 호스트(Host) 자체의 보안이 선행되어야 한다.

가장 기본적인 조치로, 호스트의 루트(root) 접근을 비활성화하고, 비밀번호 기반 인증 대신 SSH 키 기반 인증만 허용하는 것이 좋다.

호스트 보안이 확보되었다면, 다음 과정은 쿠버네티스 클러스터의 심장이라 불리는 Kube API server이 존재한다.

kubectl 명령이든 API 직접 호출이든, 클러스터 내부에서 일어나는 모든 작업과 통신은 반드시 API 서버를 통과해야 한다.

따라서 API 서버 접근을 보호하는 것이 쿠버네티스 보안의 핵심이며, 이는 두 가지 관점으로 나뉜다.

인증 (Authentication): "누가" API 서버에 접근할 수 있는가?
- 인증 방식으로는 사용자 이름/비밀번호, OIDC 토큰, LDAP 같은 외부 인증 제공자 연동 등이 존재
- '인증서(Certificates)'를 이용한 방식 존재
인가 (Authorization): "무엇을" 할 수 있는가?
- 인증된 사용자가 모든 것을 할 수 있도록 관리자 권한을 부여해서는 안 된다.
- 이를 제어하기 위해 RBAC (역할 기반 접근 제어), ABAC(속성 기반 접근 제어), 노드 인가, 웹훅 등의 인가 모델을 사용한다.

2. TLS의 기반 - 암호화의 이해 (대칭 vs 비대칭)

쿠버네티스에서 TLS가 어떻게 작동하는지 이해하기 위해서는, 먼저 암호화의 기본 원리를 알아야 한다.

해당 세션에서는 은행 계좌 접근 시나리오를 통해 암호화 방식을 설명한다.

2-1. 암호화가 없는 통신

클라이언트가 서버에 사용자 ID와 비밀번호를 그냥 전송한다.
이때 해커 (중간자)가 연결을 엿보고 있다면, 이 정보를 그대로 탈취하여 계정이 해킹된다.

2-2. 대칭 암호화 (Symmetric Encryption)

하나의 키 (대칭 키)를 사용하여 데이터를 암호화하고 복호화한다.
클라이언트가 ID/PW를 이 키로 암호화해서 보낸다고 가정하게 되면, 서버는 이 데이터를 받았지만, 키가 없어서 복호화할 수 없다.
만약 클라이언트가 복호화 키를 암호화된 데이터와 함께 보낸다면, 해커는 암호화된 데이터와 키를 모두 탈취하게 된다.
결국 해킹당하는 것은 마찬가지이며, 이것이 대칭 키 방식의 한계이다.

2-3. 비대칭 암호화 (Asymmetric Encryption)

두 개의 키 (공개 키, 개인 키)를 한 쌍으로 사용한다.
서버는 자신의 개인 키 (Private Key)는 절대 외부에 공개하지 않고, 공개 키 (Public Key)만 클라이언트에게 전송한다. (이때 해커 역시 이 공개 키를 획득할 수 있음)
클라이언트는 서버로부터 받은 공개 키를 사용해 ID/PW 같은 민감한 데이터를 암호화하여 서버로 전송한다.
해커가 이 암호화된 데이터와 공개 키를 모두 훔쳐본다 해도, 암호화에 사용된 공개 키로는 데이터를 복호화할 수 없다.
오직 서버만이 자신이 가진 개인 키를 이용해 암호화된 데이터를 안전하게 복호화할 수 있다.

3. 인증서와 CA

대칭 암호화에 비교하면 비대칭 암호화는 비교적 안전하나, 사실 비대칭 암호화도 완벽하지 않다.

만약 해커가 더 영리해져서 아예 '가짜 은행 서버'를 통째로 복제하고, 자신만의 공개/개인 키 쌍을 만들어 클라이언트를 속인다면 어떻게 될까?

클라이언트는 가짜 서버에 접속해 자신의 ID/PW를 암호화하여 전송할 것이고, 해커는 자신의 개인 키로 이를 복호화하여 정보를 탈취할 것이다.

이 문제를 해결하기 위해 '인증서(Certificate)'가 필요하다.

인증서의 역할:
1. 서버는 클라이언트에게 공개 키만 보내는 것이 아니라, 공개 키를 포함한 자신의 신원 정보가 담긴 '인증서'를 전송
2. 클라이언트는 이 인증서를 보고 서버가 "자신이 주장하는 그 서버"가 맞는지 확인할 수 있다.
CA (Certificate Authority, 인증 기관): 하지만 해커 또한 '가짜 인증서'를 위조할 수 있다.
- 이때 신뢰할 수 있는 제3자인 'CA(인증 기관)'가 등장한다.
- Symantec, DigiCert, Comodo, GoDaddy 등 공인된 CA는 조직의 신원을 검증한 후, 해당 조직의 인증서를 발급하고 보증해준다.
- 클라이언트 (주로 브라우저나 OS)는 이 CA들의 목록을 미리 신뢰하도록 설정되어 있으며, 서버가 제시한 인증서가 이 신뢰할 수 있는 CA로부터 발급된 것인지 확인하여 진짜 서버임을 최종적으로 검증한다.

4. 쿠버네티스 클러스터와 3가지 유형의 인증서

앞서 설명한 암호화와 인증서의 모든 개념은 쿠버네티스 클러스터 전반에 동일하게 적용된다.

쿠버네티스는 클러스터 내부의 모든 연결을 TLS를 통해 안전하게 보호한다.

관리자가 클러스터에 접속할 때, 마스터 노드가 워커 노드와 통신할 때, 그리고 클러스터 내부의 서비스 (API 서버가 etcd와 통신하는 등) 간의 모든 통신이 TLS로 암호화된다.

이를 위해 쿠버네티스는 3가지 유형의 인증서를 사용한다.

루트 인증서 (Root Certificates):
- 신뢰의 기준점이 되는 최상위 인증서
- 쿠버네티스 클러스터는 자체적인 CA를 두어 이 루트 인증서를 발급하고, 클러스터 내부의 다른 모든 인증서를 이 루트 CA가 보증

서버 인증서 (Server Certificates):
- 클라이언트의 연결 요청을 받는 서버 역할을 수행하는 컴포넌트를 위한 인증서이다.

클라이언트 인증서 (Client Certificates):
- 서버에 연결을 요청하는 '클라이언트' 역할을 수행하는 컴포넌트를 위한 인증서
- 이름 규칙에서 .CRT는 인증서
- .KEY는 키를 의미

5. Kube-apiserver의 이중 역할과 컴포넌트 통신

쿠버네티스의 핵심 컴포넌트들은 각자의 역할에 따라 서버 인증서 또는 클라이언트 인증서를 사용하며 서로 통신한다.

서버 인증서가 필요한 컴포넌트:
- kube-apiserver: 클러스터의 모든 요청을 받는 핵심 서버
- etcd-server: API 서버로부터 데이터 저장/조회 요청을 받는 서버
- kubelet-server: 워커 노드의 Kubelet. API 서버로부터 log, exec 등의 요청을 받기 위해 자체적으로 서버 역할을 수행
클라이언트 인증서가 필요한 컴포넌트:
- admin: kubectl을 사용하는 관리자로, API 서버에 요청하는 클라이언트.
- kube-scheduler: API 서버에 파드 정보를 요청하고 스케줄링 결과를 알리는 클라이언트
- kube-controller-manager: API 서버를 모니터링하며 상태를 조절하는 클라이언트
- kube-proxy: API 서버와 통신하는 클라이언트
- kubelet: API 서버에 자신의 상태를 보고하는 클라이언트

이때, 여기서 가장 중요한 점은 kube-apiserver의 이중 역할이다.

API 서버는 대부분의 컴포넌트에게 서버이지만, 특정 컴포넌트에게는 클라이언트로 작동한다.

API 서버가 etcd-server와 통신할 때:
- kube-apiserver는 etcd의 유일한 클라이언트
- kube-apiserver가 데이터를 저장하거나 조회하기 위해 etcd-server에 클라이언트로서 요청
API 서버가 kubelet-server와 통신할 때:
- kube-apiserver는 파드 로그를 가져오거나, 파드에 명령을 실행하기 위해 해당 워커 노드의 kubelet-server에 클라이언트로서 요청