15. Authentication - X506 Certs, kubectl, Service Account / Authorization - RBAC, Role, RoleBinding

Authentication

1. X506 Client Certs

 

 

 먼저 클러스터에 6443 포트로 API 서버가 열려있습니다. 사용자가 https로 접근하려면 k8s 설치시 kubeconfig 라고 해서 이 클러스터에 접근할 수 있는 정보들이 들어있는 파일이 있는데 위처럼 인증서 내용이 있습니다. 여기서 Client Key, crt 복사해서 가져오면 됩니다. 최초에 발급 기간과 클라이언트에 대한 개인 키를 만들고, 이 개인 키를 가지고 인증서를 만들기 위한 각각의 인증 요청서라는 csr 파일을 만듭니다. 이 CA 경우 인증 요청서를 가지고 바로 인증서를 만드는데 kubeconfig에 있는 CA crt 가 이것입니다. 클라이언트 인증서의 경우 발급기간 개인키와 인증서 그리고 클라이언트 요청서를 모두 합쳐서 만들어 집니다. 이렇게 만들어진 클라이언트 인증서가 kubeconfig 파일에 클라이언트 crt로 들어있고, Client Key도 있는 것 입니다.

 

 또한 k8s 설치할 때 kubectl도 설치를 하고, 설정 내용에 kubeconfig 파일을 통째로 kubectl에서 사용하도록 복사를 하는 과정이 있는데, 이렇게 했기 때문에 kubectl로 k8s API에 인증이 돼서 리소스들을 조회할 수 있습니다. accept-hosts 옵션으로 8001번 포트로 proxy를 열어두면 외부에서도 http로 접근할 수 있게 되는데 kubectl이 인증서를 가지고 있기 때문에 사용자는 아무런 인증서 없이 접근이 가능합니다.

 

 

2. kubectl

 

 

 외부 서버에 kubectl을 설치해서 멀티 클러스터에 접근을 하는 내용이고, 각 클러스터에 있는 kubeconfig 파일이 내 kubectl에도 있어야 합니다. 사용자는 원하는 클러스터에 접근이 가능한데, kuberconfig를 더 자세히 알아보겠습니다. 이 안에는 clusters라는 항목으로 클러스터를 등록할 수 있고, 내용으로 이름과 연결정보 그리고 CA 인증서가 있습니다. 그리고 Users라는 항목으로 사용자를 등록할 수 있는데 내용으로는 유저 이름과 이 유저에 대한 개인 키와 인증서가 있습니다.

 

 이렇게 있다면 contexts 항목으로 이 둘을 연결할 수 있는데 내용으로는 contexts 이름, 연결할 클러스터와 유저 네임이 있습니다. 이렇게 클러스터 A에 대한 contexts가 만들어졌고, 마찬가지로 클러스터 B에 대해서도 등록을 할 수 있습니다. 만약 클러스터 A에 연결하고 싶다면 kubectl config user-context context-A 라는 kubectl config 명령으로 현재 사용하고 싶은 context를 지정할 수 있습니다. 

 

 

3. Service Account

 

 

 위와 같이 k8s Cluster, k8s API 서버가 있고, Namespace를 만들게 되면 기본적으로 default 라는 이름의 Service Account가 자동으로 만들어집니다. 이 안에는 Secret이 하나 달려있는데 내용으로 CA crt 정보와 토큰값이 들어있습니다. Pod를 만들면 이 서비스 어카운트 연결이 되고 Pod는 이 토큰값을 통해 API 서버에 연결할 수 있는데, 결국 토큰값만 알면 사용자도 이 값을 가지고 API 서버에 접근할 수 있습니다.

 

 

 

Authorization

1. RBAC Overview

 

 

 쿠버네티스가 자원에 대한 권한을 부여하는 방법에서는 여러가지가 있지만 RBAC을 많이 사용합니다. 역할 기반으로 권한을 부여하며, Role과 RoleBinding이라는 오브젝트가 그 기능을 합니다. 1) 클러스터 내에는 Node, PV, Namespace 같이 클러스터 단위로 관리되는 자원과 2) Pod, Service와 같이 Namespace 단위로 관리되는 자원으로 나눌 수 있습니다.

 

 Namespace를 만들면 자동적으로 Service Account가 만들어지고, 추가적으로 더 만들 수 있는데 Service Account에 Role, RoleBinding의 설정에 따라 해당 Service Account는 Namespace 내의 자원에만 접근할 수 있고, 아니면 클러스터에 있는 자원에도 접근할 수 있게 됩니다.

 

 Role은 여러개를 만들 수 있고, 각 Role에는 Namespace 내에 있는 자원에 대해서 조회만 가능하거나 생성만 가능하도록 권한을 줄 수 있습니다. RoleBinding은 Role, Service Account로 연결해주는 역할인데 Role은 하나만 지정할 수 있고, Service Account는 여러개 지정이 가능합니다. 위를 예시로 SA, SA1은 Role1 권한으로 API 서버에 접근할 수 있게 됩니다.

 

 Service Account에서 클러스터로 접근하고 싶은 경우, 먼저 ClusterRole과 ClusterRoleBinding이라는게 만들어져 있어야 합니다. ClusterRole은 클러스터 단위의 오브젝트들을 지정할 수 있다는 것이 Role과의 차이점 입니다. 기능은 같기에 ClusterRoleBinding에 이 Service Account를 추가하게 되면 Namespace A에 있는 Service Account에서도 클러스터 자원에 접근할 수 있는 권한을 얻게 되는 것 입니다.

 

 다른 케이스로 Namespace 내의 RoleBinding이 Service Account와 연결이 됐고, Role을 지정할 때 본인의 Namespace 내에 있는 롤이 아닌 ClusterRole을 지정할 수도 있습니다. 이렇게 됐을 때 이 Service Account는 클러스 자원에는 접근하지 못하고, 자신의 Namespace B에 있는 자원만 사용이 가능합니다. 이는 그저 Role을 사용하는 것과 같은데 왜 굳이 이렇게 할까요? 모든 Namespace 마다 똑같은 Role을 부여하고 관리를 해야 되는 상황에서 각각의 Namespace 마다 똑같은 내용의 Role을 만들게 되면 이 Role에 대한 변경이 필요할 때 모든 Role을 수정해야 하는데, 이렇게 하면 관리하기 어렵게 됩니다.

 

 그래서 ClusterRole 하나만 만들어 놓고 모든 Namespace에 있는 RoleBinding이 이 ClusterRole 지정하면, 권한에 대해 변경사항이 있을 때 하나만 수정을 하면 돼서 관리가 수월해집니다. 이 방식은 모든 Namespace에 같은 권한을 만들어서 관리해야 할 때 유용합니다.

 

 

 

2. Role, RoleBinding Detail

 

 

 첫번째 경우 한 Namespace에 Pod, Svc가 있습니다. 자동으로 Service Account와 토큰키가 담겨져 있는 Secret이 있습니다. 그리고 Role을 만들건데, Pod는 코어 API이기 때문에 apiGroups에 내용을 안 넣어도 되고, resources가 다를 경우 해당 apiGroups를 넣어주어야 합니다. verbs 속성은 조회만 가능하도록 하게 하는 내용을 준 것이고, 마지막으로 RoleBinding을 만들고, roleRef 속성에 Role을 연결, subjects 속성에 Service Account 연결하면 끝입니다.

 

 이렇게 연결하면 Secret 토큰값을 가지고 이 API 서버에 접근할 수 있고, 이 토큰 권한에 따라 Namespace 내에 있는 Pod만 조회를 할 수 있게 됩니다.

 

 두번째 경우를 보면 또 새로운 Namespace가 있고, 이는 Service Account를 Admin의 권한처럼 모든 클러스터 자원에 접근을 할 수 있게 만들거면, ClusterRole의 속성을 위처럼 줍니다. ClusterRoleBinding을 만들고, 본인의 Service Account와 연결을 하면 됩니다. 그래서 이 token으로 API 서버에 접근을 하면 다른 Namespace에 있는 자원은 물론이고, 클러스터 단위의 자원에서도 조회나 생성이 가능합니다.