Cloud Computing/Kubernetes

Kubernetes - Authentication, Authorization

HwanJae 2021. 1. 22. 15:37

이번에는 Kubernetes에서 지원하는 API 접근제어 정책으로 Authentication, Authorization에 대해 알아보도록 하겠다.

 

Authentication

사용자가 Kubernetes Cluster로 Https 접근을 하기 위해서는 쿠버네티스 설치시에 클러스터로 접근할 수 있는 정보가 담긴 파일을 Kubeconfig에 담아두어야 한다. 즉, 클라이언트 인증서가 kubeconfig에 저장되어 있으면 된다.

kubeconfig에는 CA crt, Client crt, Client key가 포함되어있다.

 

기본적으로 저장되는 장소는 /etc/kubernetes/admin.conf인데 내부를 확인해보면 각각의 인증서가 base64로 인코딩된 상태로 저장되어 있다.

각각의 인증서 내용을 확인해보기 위해서는

Client.crt
grep 'client-certificate-data' /etc/kubernetes/admin.conf | head -n 1 | awk '{print $2}' | base64 -d

Client.key
grep 'client-key-data' /etc/kubernetes/admin.conf | head -n 1 | awk '{print $2}' | base64 -d

커맨드를 활용해서 디코딩된 키 값을 조회할 수 있다.

 

kubectl에서 kubeconfig 파일을 kubectl에 복사해서 사용하도록 설정해두면 kubectl로 쿠버네티스의 API인증서를 조회할 수 있으며, Accept-hosts 옵션을 이용하여 프록시를 열어두게 되면 kubectl이 인증서를 담아두고 있기 때문에 사용자가 인증서를 가지고 있지 않아도 외부에서 http를 통해 접근하는 것이 가능하다.

 

다음으로 Kubernetes Cluster에 Namespace를 만들어두면, 기본적으로 ServiceAccount가 만들어지는데, 이 곳에 존재하는 Secret에서 CA crt와 토큰값을 조회할 수 있다.

Pod를 생성하게 되면 해당 Pod는 Namespace에 존재하는 ServiceAccount와 연결되며 Pod는 ServiceAccount 내에 있는 토큰 값을 통해 API Server와 연결이 가능해진다.

 

Authorization

Kubernetes가 자원에 대한 권한을 지원하는 Authorization 정책은 여러가지가 있는데 이번에는 그 중 하나인

RBAC (Role-Based Access Control)에 대해 알아보고자 한다. 

 

쿠버네티스는 자원을 Cluster 단위로 관리되는 자원 (Node, PV, Namespace) 과 Namespace 단위로 관리되는 자원 (Pod, Service) 로 나눌 수 있다.

 

Namespace 단위로 관리되는 자원에 RoleBinding

Namespace를 만들게 되면 앞서 자동적으로 ServiceAccount가 생성된다고 했다.Role은 여러 케이스에 대해 여러 Role을 작성할 수 있으며 각 Role 에는 Namespace 내에 있는 자원에 대해 조회만 가능하거나 생성만 가능하도록 권한을 부여할 수 있다.

 

RoleBinding은 Role과 ServiceAccount를 연결해주는 역할인데, ServiceAccount는 여러 개를 지정하여 연결할 수 있지만, Role은 한 번에 한 가지만 지정하여 연결할 수 있다.

 

Cluster 단위로 관리되는 자원에 RoleBinding

또한 ServiceAccount가 Cluster 자원에 접근하고자 할 때는 ClusterRole과 ClusterRoleBinding을 사용한다.Namespace 내에 있는 RoleBinding이 ServiceAccount와 연결되어 있고, RoleBinding이 Namespace 내에 있는 Role이 아닌, ClusterRole을 지정하고 싶을 경우에는 ClusterRoleBinding을 통해 서로 연결해주게 되는데,이러한 경우에 ServiceAccount는 Cluster 자원에는 접근하지 못하고 자신의 Namespace 내에 있는 자원만 사용할 수 있다.

 

이렇게 되면 결국 ServiceAccount가 Namespace 내에 있는 Role을 연결한 것과 다를 바가 없어 보이지만 해당 상황은 모든 Namespace 마다 똑같은 Role을 부여하고 관리해야 하는 상황에서, 각각의 Namespace 마다 Role을 만들게 되면 이 Role의 변경이 필요할 경우 모든 Namespace 내에 있는 Role을 변경해야 하는 번거로움이 발생한다.이러한 번거로움을 방지하기 위해서 ServiceAccount를 ClusterRole과 연결해주고, ClusterRole을 통해 일괄적으로 Namespace에 대한 Role을 수정하는 식으로 관리한다면 더욱 관리하기에 수월해질 것이다.

 

저작자표시