CKA 준비과정 - Security (3) / 인증 API

이제까지 클러스터 관리자로써, 클러스터 내 통신 시 TLS 보안이 어떻게 적용되고 이 때 인증 과정이 어떻게 이루어지는지 확인하였다.

 

이 인증서는 CA(Certificate Authority) 기관이 보증한다는 것을 학습하였고, CA 서버가 인증서를 발급해줌을 확인하였다. 

또한 앞서 관리자는 클러스터에 접속하기 위해서는 인증서와 개인키가 필요하다는 것을 학습했다.

 

그렇다면, 새로운 관리자가 클러스터에 접속하기 위해서는 어떻게 해야 하는가?

새로운 인증서와 키 쌍을 발급해서 줘야한다.

 

새로운 관리자는 개인키를 생성하여 인증서 서명 요청을 작성하여 기존의 관리자에게 보낸다.

기존 관리자는 인증서 서명 요청을 CA 서버로 가져가 CA 서버의 개인키와 루트 인증서를 통해 서명하고, 새로운 관리자에게 다시 돌려보낸다. 이제 새로운 관리자는 클러스터에 접속할 수 있다.

 

이러한 과정은 인증서가 만료될 때마다 반복된다.

 

그렇다면, 기존 관리자가 CA 서버에 인증서를 발급 요청하였다고 했을 때 CA 서버는 쿠버네티스 내에 존재한다고 볼 수 있다.

CA는 그 의미 자체로 키와 인증서 파일의 쌍을 말한다. 이 한 쌍의 파일에 접근 권한을 가진사람은 쿠버네티스 인증서에 서명할 수 있다. 추가로 새로운 관리자를 데려올 수 있다는 말이다. 따라서 CA는 아무나 접근할 수 있어서는 안된다. 특정한 서버 내에서 보호되어야 한다.

==> 즉, CA 파일을 보관하는 서버가 CA 서버가 된다. 해당 서버에는 인증서와 키 파일이 안전하게 저장되며 다른 서버에는 저장되지 않는다.

 

쿠버네티스에는 자동화된 방법으로 인증서를 관리하고 신규 발급 요청에 대한 서명을 진행하며, 만료되면 자동으로 갱신하는 API 가 존재한다. 이것이 바로 Certificate API 이다.

 

Certificate API의 동작 과정은 아래와 같다.

 

1. Certificates API를 호출하여 쿠버네티스로 인증서 서명 요청을 전송한다.

2. 관리자가 인증서 서명 요청을 받으면 마스터 노드에 로그인해 CertificateSigningRequest Object(인증서 서명 요청 객체)를 생성한다.

3. 해당 개체를 생성하면 모든 인증서 서명 요청을 클러스터 내 관리자가 볼 수 있다. kubectl 명령을 통해 요청을 객체를 활용하여 검토하고 승인한다.

4. 해당 인증서는 추출되어 다른 사용자와 공유할 수 있다.

 

위에서 설명한 CertificateSigningRequest Object, 인증서 서명 요청 객체는 yaml 파일로 생성한다.

일반적인 다른 쿠버네티스 리소스와 동일하게 yaml 파일 로 생성한다.

파일 내에 사용자의 그룹을 명시하고, 사용처를 문자열 목록으로 기록한다. request 필드는 인증서 서명 요청을 지정하는 부분으로, base64 명령어를 통해 암호화하여 넣어야 한다.

 

위 객체를 생성하면 클러스터 내 모든 관리자가 인증서 서명 요청을 확인할 수 있다. 아래 명령어를 통해서 확인 가능하다.

kubectl get csr
kubectl certificate approve

get csr 명령어로 CSR을 확인할 수 있고 approve 명령어를 통해 요청을 승인할 수 있다.

 

위와 같은 작업은 쿠버네티스 클러스터 내 Controller Manager에 의해 수행된다.

Controller Manager 내에는 CSR-approving, CSR-signing 컨트롤러가 들어가 있다.

여기서 approving 은 승인, signing은 서명 작업을 수행한다.

 

추가로, Controller Manager 서비스 구성에는 인증서와 키 경로를 지정하는 두 옵션이 존재한다. 해당 옵션은 사용자가 지정할 수 있다.