Certificates API
나는 클러스터 관리자로서 전체 클러스터를 설정하는 과정에 CA 서버와 다양한 구성 요소에 대한 인증서 뭉치를 설정했다. 팀에 새로운 관리자가 왔다. 클러스터에 접속할 수 있게 인증서와 개인키 쌍을 줘야 한다.
그녀는 개인키를 만들어 인증서 서명 요청을 작성해서 나한테 보낸다.
나는 클러스터의 유일한 관리자이므로 인증서 서명 요청을 내 CA 서버로 가져가서 CA 서버가 CA 서버의 개인키와 루트 인증서를 이용해서 서명하게 한다.
인증서가 생성되면 인증서를 그녀에게 다시 보낸다. 이제 그녀는 자신만의 유효한 인증서와 키를 갖고 있다.
인증서에는 유효기간이 있기 떄문에 유효기간이 만료될 때마다 새로운 CSR을 생성하고 CA에 서명받는 같은 과정을 따른다.
CA 서버란 무엇일까?
CA는 우리가 생성한 키와 인증서 파일의 쌍이다. 이 한 쌍의 파일에 접근 권한을 가진 사람은 쿠버네티스 인증서에 서명할 수 있다.
CA에 접근 가능하면 원하는 만큼 많은 사용자를 생성하고 원하는 특권을 넣을 수 있다.
그래서 이런 파일은 안전한 서버에서 보호 및 저장되어야 한다. 즉, CA 파일이 안전하게 저장되는 서버가 CA 서버이다.
인증서에 서명하고 싶을 때마다 CA 서버에 로그인해야만 할 수 있다.
쿠버네티스 클러스터에서 마스터 노드에 CA 파일들이 위치하기 때문에 마스터 노드는 CA 서버이다.
쿠버네티스엔 자동화된 방법으로 인증서를 관리하고 요청에 서명하는 Certificates API가 존재한다.
- Certificates API를 통해 쿠버네티스로 인증서 서명 요청이 보내진다.
- 관리자가 인증서 서명 요청을 받으면 인증서서명요청(CSR)을 생성한다.
- CSR 개체가 생성되고 나면 모든 인증서서명요청은 클러스터 관리자들이 볼 수 있다. kubectl 명령으로 요청을 쉽게 검토하고 승인할 수 있다.
- 이 인증서는 추출되어 사용자와 공유될 수 있다.
위의 자세한 과정을 살펴보자.
먼저 사용자는 키를 만들고 만들어진 키를 사용해서 인증서서명요청(CSR)을 생성한다.
그런 다음 관리자에게 CSR을 보낸다. 관리자는 키를 받아 인증서서명요청 개체를 만든다.
인증서서명요청 개체는 다른 쿠버네티스 개체처럼 매니페스트 파일을 통해 생성된다. spec 영역에 사용자가 속해야 할 그룹, 계정의 사용 용도를 명시하고 request 필드에 CSR을 지정한다.
이때, base64로 인코딩된 CSR의 텍스트를 사용해야 한다.
일단 개체가 생성되면 kubectl get csr 명령어를 통해 관리자들은 모든 CSR을 볼 수 있다. 새 요청을 식별하고 kubectl certificate approve 명령어를 통해 요청을 승인할 수 있다.
쿠버네티스는 CA 키 쌍을 이용해 인증서에 서명하고 사용자를 위한 인증서를 생성한다.
이 인증서는 추출되어 사용자와 공유될 수 있다.
CSR의 내용을 decode해서 확인할 수 있다.
이제 어떻게 작동하는지 확인했으니 누가 이걸 수행하는지 알아봐야 한다.
쿠버네티스의 컨트롤 플레인을 보면 kube-api server, scheduler, controller manager 등을 볼 수 있다.
인증서와 관련된 모든 작업은 controller manager에 의해 실행된다.
controller manager를 자세히 보면 CSR-APPROVING, CSR-SIGNING을 확인할 수 있다.
CSR-APPROVING은 승인, CSR-SIGNING은 서명 작업을 책임진다.
controller manager 서비스 구성에는 인증서와 개인키를 지정하는 두 옵션이 있다. controller manager가 인증서에 서명하기 위해서 CA 서버의 인증서 경로와 개인키가 필요하기 때문이다.
테스트 문제를 기록해보도록 하겠다.
CertificateSigningRequest(CSR) 개체 생성하기
- csr 파일을 base64로 인코딩하기
cat akshay.csr | base64 -w 0
- CertificateSigningRequest 매니페스트 파일 작성하기
CSR이 pending 상태인 것을 확인할 수 있다.
- CSR 요청을 승인한다.
kubectl certificate approve akshay
CSR 요청을 승인했기 때문에 CSR이 Approved,Issued 상태인 것을 확인할 수 있다.
kubectl certificate deny 명령어를 사용해서 CSR 요청을 거부할 수 있다.
테스트 통과 완료
KubeConfig
kubectl 도구는 기본값으로 '$HOME/.kube/config' 파일을 찾는다. 이것이 지금까지 kubectl 명령에 대한 옵션을 지정하지 않은 이유이다.
kubeconfig 파일에는 Clusters, Contexts, Users 이렇게 세 가지 영역이 있다.
Clusters는 접근이 필요한 다양한 쿠버네티스 클러스터를 말한다. 예를 들어, Development, Production, Google 등이 있다.
Users는 이런 클러스터에 접근 권한이 있는 사용자 계정이다. 예를 들어, Admin, Dev User, Prod User 등이 있다.
마지막으로 Contexts는 어떤 사용자 계정이 어떤 클러스터에 접근하기 위해 사용되는지를 정의한다.
'--server', '--certificate-authority' 사양은 Clusters 영역으로 간다.
'--client-key', '--client-certificate' 사양은 Users 영역으로 간다.
그런 다음 Context를 생성해 User를 이용해 Cluster에 접근하는 지정 사항을 지정한다.
이제 kubeConfig 매니페스트 파일을 살펴보자.
clusters, contexts, users 세 영역이 있고 각각 배열 형식이다. 그래서 다중으로 설정할 수 있다.
다중 컨텍스트를 지정하기 위해 매일 접근하는 클러스터와 사용자를 여러개 지정할 수 있다.
파일이 준비되면 어떤 개체도 생성할 필요가 없다.
파일은 이대로 두고 kubectl 명령에 의해 kubeconfig 파일 설정값이 읽힌다.
kubeconfig 파일에 current-context 필드를 추가해 기본 컨텍스트를 지정할 수 있다.
사용 중인 현재 파일을 보려면 kubectl config view 명령을 실행하면 된다.
앞서 말했듯이 어떤 kubeconfig 파일을 사용할지 지정하지 않으면 폴더에 위치한 홈 디렉토리에 있는 기본 파일을 사용하게 된다.
다른 kubeconfig 파일을 보고 싶다면 옵션으로 파일을 명시해야 한다.
현재 컨텍스트를 변경하기 위해 kubectl config use-context 명령을 사용하면 된다.
kubectl config 명령어를 사용해서 파일에서 다른 수정을 하거나 아이템을 삭제하할 수 있다.
kubeconfig 파일의 context 영역은 namespace라는 추가 필드를 가질 수 있다.
namespace 필드를 명시하면, 특정 컨텍스트로 전환하면 자동으로 특정 네임스페이스에 들어가게 된다.
kubeconfig 파일에서 인증서 파일 경로를 지정할 때 전체 경로를 명시하는 것이 좋다.
인증서 파일 경로를 명시하는 대신 인증서 자체의 컨텐츠를 인코딩해서 명시할 수도 있다.
테스트 문제를 기록해보도록 하겠다.
my-kube-config 파일을 default kubeconfig 파일로 정하는 방법은 다음과 같다.
테스트 통과 완료
