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

이제까지 쿠버네티스 내 인증에 대한 부분을 계속 학습하였다.

이제는 클러스터 내에서 인증을 어떻게 활용하는지 알아보자.

 

클러스터 관리자는 모든 종류의 작업을 수행할 수 있다. 배포 또는 파드 추가 및 삭제, 노드 관리 등의 작업을 모두 할 수 있다.

하지만 다른 관리자들도 모두 클러스터에서 위와같은 작업을 전부 수행할 수 있어서는 안된다. 각 사용자는 업무에 맞는 권한만을 가져야 한다. 각 관리자의 계정마다 접근 권한을 조정하여 제어할 수 있도록 해야한다.

 

쿠버네티스는 4가지의 인증 메커니즘을 지원한다.

Node Authorizer / ABAC (Attribute Based Access Control) / RBAC(Role Based Access Control) / Webhook

하나씩 알아보자.

 

1. Node Authorizer

kube-apiserver는 관리자에 의해 액세스되고, kubelet도 프로세스를 위해 kube-apiserver에 접근한다.

kubelet은 서비스, 노드, 파드에 대한 정보를 apiserver로부터 정보를 읽어오고 노드 상태 정보를 전달한다.

이러한 kubelet 요청은 Node Authorizer 에 의해 처리된다.

 

API group에서, kubelet은 system:node 그룹의 일부이다. 따라서 system:node:kubelet이 된다.

system:node 그룹의 일부로 사용자가 요청하면 Node Authorizer가 승인하고, 권한을 부여받아 노드 상태 정보를 전달 및 읽어올 수 있게 된다. 이러한 방식으로 Node 인증이 이루어진다.

 

 

2. ABAC(Attribute-Based Access Control)

ABAC는 사용자 또는 사용자가 속한 그룹을 권한 정책 파일로 연결하는 것이다.

dev-user는 pod를 확인, 생성, 삭제할 수 있도록 정의하고 apiserver에 파일을 전달한다.

각각 다른 사용자 또는 그룹에 대해 정책 정의파일을 생성해 둘 수 있다. 다만 위 방법은 정책이 변경될 때마다 정책 파일을 수정하고 kube-apiserver를 재시작해야 한다. 따라서 권장되지 않는 방법이다.

 

 

3. RBAC(Role Based Access Control)

ABAC가 사용자를 권한 정책 파일로 연결했다면 RBAC 는 역할을 직접 정의한다.

Developer 라는 역할을 정의하고 각 사용자들을 연결해주기만 하면 된다. 따라서 정책이 변경되면 역할을 수정해주면 연결되어있는 모든 사용자들의 정책에 즉시 반영된다. 일반적으로 많이 사용되는 방법이다.

 

 

4. Webhook

클러스터 내에서 권한을 관리하는 것이 아닌, 외부에서 접근 권한의 관리가 필요할 때 사용하는 방법이다.

Open Policy Agent 는 클러스터에게 질의를 하여 허가를 받아 접근을 할 수 있도록 돕는다.

쿠버네티스는 외부로부터 접근을 원하는 사용자의 정보 및 요구사항 액세스 정보와 함께 Open Policy Agent에 API 요청을 보낸다.  Open Policy Agent는 요청을 받으면 허용 여부를 결정하고 응답한다.

 

5. 기타 다른 모드

AlwaysAllow : 모든 요청을 허용

AlwaysDeny : 모든 요청 거절

kube-apiserver의 --authorization-mode 옵션을 통해 위 두가지 옵션을 지정할 수 있으며, 기본값으로 AlwaysAllow가 설정되어 있다.

 

클러스터 Role과 Role 바인딩하기

Namespace 내에서 Role을 생성할 수 있음을 사전에 학습했다. 또한, Role 생성 시 Namespace를 별도로 지정하지 않으면 기본 default namespace에 생성된다. Role은 생성된 namespace 내에서만 접근 제어가 가능하다.

 

Namespace 학습 시, 그룹화 및 파드 / 배포 / 서비스 단위로 관리를 할 때 많이 사용하는 기능임을 학습했다.

하지만 노드는 물리적 리소스로 그룹화가 될 수 없어 Namespace로 관리할 수 없다. 노드는 클러스터 범위 리소스로, 어떠한 namespace와도 연결될 수 없다.

 

클러스터 범위 리소스(Cluster Scoped)는 생성 시 namespace를 지정하지 않는 리소스들이 소속된다. 노드나 영구적 볼륨과 같은 리소스가 해당한다.

 

따라서 쿠버네티스의 모든 리소스는 namespaced 또는 Cluster scoped 둘 중 하나에 소속되게 된다.

 

여기서 Namespace 에 속하는 리소스는 인증을 위해 Role과 Role binding을 사용한다.

Cluster Scoped 에 속하는 리소스는 인증 시 ClusterRole과 ClusterRole Binding을 사용한다.

 

ClusterRole과 Role의 차이는 소속된 리소스의 차이이다. Role 정의 파일 생성 시 지정하는 필드에 차이가 있다.

 

Role과 Role binding 모두 정의 파일을 통해 리소스를 생성할 수 있다.

Role 파일의 경우 rules 영역에 apiGroups / resources / verbs 필드를 지정한다.

RoleBinding 개체는 사용자에 Role을 바인딩하는 역할의 개체이다.

subjects 영역에 사용자의 정보를, roleRef 영역에 clusterrole 리소스를 지정한다.

 

위 이미지의 예시는 일반 role이 아닌 clusterrole이다. Clusterrole은 Cluster Scope 내 리소스에 대해 적용되는 Role이지만, namespaces 내 리소스에도 적용은 가능하다. 하지만 해당 경우에는 사용자는 모든 namespace 리소스에 접근할 수 있다.