Kubernetes Cluster 접근시 클러스터가 인증을 처리하는 방법

1. 쿠버네티스 클러스터 접근 주체

쿠버네티스 클러스터에 접근하는 주체에는 관리자, 개발자 그리고 서비스 어카운트가 있다. 쿠버네티스는 파일, 인증서 그리고 LDAP 같은 수단을 통해 접근 주체의 인증을 처리하고 있다.

 

쿠버네티스 클러스터의 대표적인 컴포넌트인 kube-apiserver에 접근하는 방법으로 kubectl을 이용한 방법과 curl을 이용한 방법이 있다. 이 때 클러스터는 유저의 인증 및 요청을 처리한다. 클러스터는 4가지 유형으로 유저의 인증을 처리한다.

 

1.1 유저 인증 처리 방법

 

- 유저 아이디 + 패스워드

- 토큰

- 인증서

- 외부 인증 서비스

 

1.1.1 유저 아이디 + 패스워드 / 토큰

.csv 파일을 만들어 해당 파일 안에 패스워드, 유저 이름, 유저 아이디, 그룹을 명시한다.

 

이후 서비스나 yaml 파일을 통해 --basic-auth-file 옵션 또는 --token-auth-file 옵션을 통해 해당 파일을 지정한다. 파일을 지정할 때는 해당 파일이 위치한 노드의 volume및 파드에서 해당 volume을 마운트해야 한다.

 

유저 아이디와 패스워드 그리고 인증서로 인증을 처리하는 경우 인증서를 사용해 인증을 처리하는 것보다 보안에 취약할 수 있다.

 

1.1.2 OPENSSL 인증서를 사용한 인증

인증서를 살펴볼 때 우선적으로 CA( CERTIFICATE AUTHORITY )를 우선적으로 살펴보아야 한다. CA를 먼저 생성한 이후 해당 CA를 바탕으로 클라이언트 인증서와 서버 인증서를 생성할 수 있기 때문이다. CA는 신뢰를 생성하는 주체로 인증서 발급과 인증서의 유효성을 검증하는 역할을 수행한다. CA가 발급되는 과정은 아래와 같다.

1.1.2.1 CA 인증서

1. 키를 생성한다.

2. 정보가 적혀있는 인증서를 생성한다.

3. 생성한 키와 인증서를 활용하여 서명이 있는 인증서(CA)를 생성한다.

 

클라이언트 인증서를 발급하는 과정은 CA를 발급하는 과정과 유사하지만 최종 서명이 있는 클라이언트 인증서를 생성할 때 키 + 인증서 + CA가 있어야지만 유효한 클라이언트 인증서를 생성할 수 있다.

1.1.2.2 클라이언트 인증서

요청 주체와 관련된 인증서를 클라이언트 인증서라고 한다. 클라이언트 인증서를 만드는 과정에서 그룹을 지정할 수 있는데 그룹은 해당 인증서를 사용하는 클라이언트(사용자 혹은 서비스계정)가 속한 권한 범위를 지정하는 역할을 한다. 아래와 같이 설정 할 경우(system:masters) 클러스터에 대한 최상위 관리자 권한을 할당한 것이다. 따라서 클러스터 관리자 계정만 포함하게 하며 세분화된 권한이 필요한 경우 개별 그룹 및 역할을 구성해야 한다. (세분화된 권한을 설정하는 방법이 궁금하다면 클릭)

 

 

앞선 예시를 들어 클라이언트 인증서를 생성했는데 위 인증서는 클러스터를 관리하는 관리자 인증서를 생성한 경우에 해당한다. 클러스터를 관리하는 관리자 인증서 이외에도 클라이언트 인증서의 종류에는 대표적으로 아래가 있다. 모두 요청의 주체라는 공통점이 있다.

 

- 관리자 인증서

- 스케줄러 인증서

- 컨트롤러매니저 인증서

- kube-proxy 인증서

- apiserver-kubelet 인증서

- apiserver-etcd 인증서

- kubelet 인증서

 

미리 설정된 권한

system:masters

관리자 그룹으로 모든 API 요청을 실행할 수 있는 최고 권한을 부여받습니다. 모든 네임스페이스와 리소스에 접근 가능하고 RBAC 영향을 받지 않습니다.

 

system:nodes

노드에 할당되는 기본 그룹입니다.

 

system:authenticated

인증된 사용자에게 할당되는 기본 그룹입니다. 하지만 이 그룹은 특정권한이 없어 그룹에 추가적인 RBAC 설정을 통해 권한을 부여합니다.

 

system:unauthenticated

인증되지 않은 사용자를 위한 그룹입니다.

 

system:serviceaccounts:<namespace>

d네임스페이스별 서비스 어카운트에 권한을 부여하여 RBAC 정책을 통해 특정 네임스페이스나 리소스에 접근할 수 있는 권한을 설정할 수 있습니다.

 

1.1.2.3 서버 인증서

서버 쪽 인증서에는 대표적으로 아래가 있다. 서버 인증서를 생성하는 과정 또한 클라이언트 인증서를 생성하는 과정과 동일하다. 

 

- etcd 인증서

- apiserver 인증서

- kubelet  인증서

etcd

etcd 인증서의 경우 루트 etcd 서버 이외에도 추가적으로 etcd를 운영 할 경우 etcd 노드가 TLS 통신을 위해 위 그림과 같이 루트 etcd 인증서 관련 설정 이외에도 peer etcd 관련 인증서를 설정해야 할 수 있다. 

 

kube-apiserver

kube-apiserver와 TLS 통신을 하기 위해서 파일(openssl.cnf)을 통해 통신 대상을 지정해야 한다. 아래 그림 [alt_names] 옵션 하위 항목에 아이피와 DNS를 설정할 수 있는데 해당 값을 지정함으로써 클러스터 내 노드들이 TLS 인증서를 통해 kube-apiserver와 안전하게 연결할 수 있다.

 

kube-apiserver 설정은 서비스 또는 yaml파일을 통해서 설정할 수 있다. TLS 연결을 설정하기 위한 인증서를 지정하기 위해 위 그림과 같이 클라이언트 인증서와 서버 사이드 인증서를 설정할 수 있다. 클라이언트 인증서로는 kube-apiserver에서 etcd 또는 kubelet으로 요청하기 위해 필요한 클라이언트 인증서가 있다. 서버 사이드 인증서로는 kube-apiserver임을 확인하는 인증서가 있다.

 

kubelet

kubelet 인증서의 경우 노드 별로 인증서를 설정해주어야 한다. 왜냐하면 kubelet이라는 컴포넌트는 노드별로 구성되기 때문이다. 인증서를 만드는 과정은 앞서 말한 클라이언트 인증서를 만드는 과정과 같다. 해당 과정에서 키를 통해 사인이 없는 인증서를 만들 때 권한을 지정해주는 것을 살펴 볼 필요가 있다.

 

SYSTEM:NODES

SYSTEM:NODES를 통해 kubelet은 클러스터의 모든 노드에서 kubelet 기능을 수행할 수 있습니다.

 

system:node:node-name

system:node:node01 같은 형식의 경우 kubelet이 특정 노드에 대한 권한만을 부여합니다.

 

1.1.3 OPENSSL 인증서를 활용한 클러스터 환경설정

쿠버네티스 클러스터에서 api를 호출 할 때 마다 인자로 관련 인증서 파일을 지정해야 하지만 그렇게 하는 것은 불편하므로 쿠버네티스에선 KubeConfigFile을 통해 호출 할 때마다 인자로 인증서를 지정하지 않게끔 기능을 제공한다. 해당 파일은 홈경로에서 $HOME/.kube/config 디렉터리 내부에 존재한다.

 

해당 파일에는 Clusters Contexts Users 섹션이 있다. 그래서 여러 클러스터 환경을 구축할 수 있다. Contexts의 경우 클러스터와 Users를 조합한 것이다. 예를 들어 배포 환경에서 관리자 계정으로 현재 클러스터 계정을 사용하고 싶을 경우 Admin@Production. 조합을 통해 Contexts를 구성할 수 있다.

 

왼쪽 그림을 살펴보면 클러스터 구성 설정 파일을 확인할 수 있는데 크게 clusters, contexts, users 영역이 있다. CA인증서를 처음 만들었을 때 해당하는 값이 cluster에 certificate-authority 부문에 들어간다. 유저의 경우 클라이언트 인증서를 만들었을 때 만든 키와 인증서가 각각 client-key와 client-certificate 필드 부문에 들어간다. 컨텍스트에는 클러스터와 유저에서 지정한 이름의 조합으로 이름을 구성하고 각각의 이름을 cluster와 user필드에 명시하여 클러스터를 구성한다.

 

한 가지 주의 사항으로 인증서 관련 항목을 적을 때 절대 경로를 적는 것이 좋고 그 것보다 좋은 방법으로는 해당 파일의 데이터를 base64로 인코딩해서 직접 적는 부문이 권장된다.

 

해당 파일이 여러 컨텍스트를 포함하면서 어떤 컨텍스트를 사용해야 할지 지정해야 하는 시점에 current-context 필드에 컨텍스트 중 하나를 지정해서 기본 컨텍스트로 설정할 수 있다. 해당 파일은 kubectl config view 명령어를 통해 확인할 수 있다. kubectl config use-context prod-user@production 또한 왼쪽 명령어와 같이 컨텍스트의 이름을 지정하면 명령어를 통해 클러스터 환경을 변경할 수 있다.