CKA 준비과정 - Security (2) / TLS

앞서 쿠버네티스간 리소스의 통신은 TLS 보안이 적용되어 있음을 알아보았다.

 

그렇다면 TLS 보안은 어떻게 이루어지는가?

 

TLS 는 대칭키, 공개키 암호화 방식을 복합적으로 사용한다.

공개키 방식은 한 쌍의 개인키, 공개키를 사용하며 공개키로 암호화하고 개인키로 복호화하는 방식이다.

대칭키 방식은 암, 복호화에 같은 키를 사용한다.

 

암호화된 통신을 진행할 때, 대칭키만 이용해서 암호화한다면 공격자가 키만 얻어낸다면 복호화를 쉽게 진행할 수 있다.

따라서 공개키 암호화 방식을 섞어 사용한다.

 

공개키 암호화 방식을 사용하여 대칭키를 상대에게 전달한다. 과정은 아래와 같다.

openssl genrsa -out my-bank.key 1024
openssl rsa -in my-bank.key -pubout > mybank.pem

1. openssl 을 통해 공개키, 개인키 쌍을 생성한다.

2. 사용자는 HTTPS 를 사용해 웹사이트에 액세스하면 서버로부터 공개키를 받는다.

3. 사용자의 브라우저가 공개키를 이용해 대칭키를 암호화하고 서버로 전송한다.

4. 서버는 개인키로 메시지를 해독하고 대칭키를 회수한다.

5. 사용자와 서버는 같은 대칭키를 활용하여 데이터를 암호화하여 보안 통신을 시작한다.

=> 해당 과정에서, 공격자는 개인키가 없기 때문에 암호화된 대칭키를 복호화 할 수 없다.

 

하지만 이 때, 공격자가 서버를 위장하여 사용자를 "피싱" 할 수도 있다.

따라서 서버는 자신이 안전한 서버임을 보증해야 한다. 이를 위해서는 인증서에 "서명" 이 필요하며, 이 인증서를 보증해줄 기관이 필요하다. 만약 보증이 없다면 인증서가 있다고 하더라도 경고문이 발생한다.

 

CA(Certificate Authority) - 보증 기관이란 무엇인가?

인증서를 발급해주고 유효성을 검증해주는 기관이다. 공격자가 같은 인증서를 발급받으려 하면, 동일한 인증서는 단 하나만 존재할 수 있으므로 유효하지 않은 인증서가 발급되어 경고문이 발생한다.

 

인증 기관은 여러 기관들이 있다. 각 기관들은 개인키와 공개키 쌍을 별개로 가지며, 인증서가 생성될 때 개인키로 서명을 진행한다. 이 인증 기관들의 공개키는 브라우저에 탑재되어 있어 해당 CA가 서명한 인증서임을 알 수 있다.

 

위와같은 모든 암호화 과정은, PKI(Public Key Infrastructure) 라는 과정으로 요약되어 불린다.

 

 

이제 쿠버네티스에서 TLS의 활용을 알아본다.

 

마스터 노드와 워커 노드간의 통신은 암호화가 적용되어야 한다. 각

클러스터의 기본 요소들 중, 서버 구성 요소가 있으며, 해당 서버들과 각 노드들이 통신함으로써 서비스가 제공된다.

이 때, 이 서버들과 노드들은 TLS 보안을 적용하여 통신한다.

 

서버 구성요소들은 익히 알고있는 kube-apiserver, ETCD Server, kubelet server 이다. kubelet server는 워커 노드에 위치하며, kube-apiserver와 통신하기 위한 https 프로토콜을 제공한다. 따라서 kubelet server는 인증서와 공개키/개인키 쌍을 요구한다.

 

서버 인증 구성요소

3가지의 클러스터 서버들은 각자 인증서와 키 한쌍을 가진다.

 

다음은 쿠버네티스 클라이언트 구성요소들의 TLS 적용을 알아본다.

쿠버네티스의 클러스터 내 클라이언트 구성요소들도 이미 학습하였다.

우선, kube-apiserver에 접근하는 클라이언트는 kubectl REST API를 사용하는 관리자이다. 관리자는 apiserver 에 접근 시 인증하기 위해 인증서과 키를 가진다.

kube-scheduler 는 kube-apiserver를 통해 스케줄링을 진행하는 프로그램이다. 스케줄링을 진행하여 apiserver가 적절한 워커 노드에 파드를 배정하도록 한다. 이 역시 apiserver에 클라이언트로서 접근하기 때문에, TLS 인증서를 통해 ID를 확인해야 한다. 따라서 인증서와 키가 필요하다.

kube-controller-manager 도 apiserver에 접근하는 클라이언트이다. 따라서 인증서와 키가 필요하다.

kube-proxy 역시 apiserver 에 접근하는 클라이언트이다. 따라서 인증서와 키가 필요하다.

이외에 ETCD, kubelet 서버와도 서버-클라이언트 관계로 통신하게 되며 이 때에도 인증서와 키가 필요하다.

 

즉, kube-apiserver 는 서버, 나머지 구성요소들은 클라이언트로서 서버-클라이언트 관계가 형성되며 이 때 인증서와 키를 통해 ID를 인증하여 TLS 통신을 하게 된다.

 

이 클러스터 내에서 사용되는 인증서 역시도 CA를 통한 인증이 필요하다.

따라서 CA로부터 인증서와 키를 발급받아 클러스터 내에서 활용한다.