인사이트리포트

들어가며

Kubernetes 환경을 사용하는 고객들이 많아지고 있으며, 이에 따른 보안 강화도 중요해지고 있다.

이번 리포트에서는User / App 에 불필요한 권한 설정이 되어 있는 상태로 사용하는 사례가 많으며, 이에 따른 보안 취약점을 줄일 수 있는 방법을 찾고자 한다. Kubernetes에서 제공 되는 RBAC, kubeconfig 설정 방법을 활용하여, OS 계정에 각각 권한을 부여해 사용 할 수 있다.

1. RBAC

최소한의 사용 권한을 필요한 Resource 에만 주는 것을 CNCF 에서는 권장하고 있다.

Kubernetes 에서는 RBAC(Role-Based Access Control) 역할 기반 액세스 제어를 제공하며, RBAC 는 Kubernetes 내의 Resource 들을 안전하게 사용하기 위한 보안 장치이다.

ClusterRole, ClusterRoleBinding, Role, RoleBinding 4개의 Object 가 존재하여, 이를 활용해 User, Group, Service Account 에게 필요한 Resource 와의 역할 및 권한 제어를 제공한다.

1.1 ClusterRole 과 Role

• ClusterRole : User, Group, Service Account가 Cluster 전체 (모든 Namespace) 의 Resource 접근 및 권한 제어 설정을 할 수 있다.
• ClusterRoleBinding : 허가 된 인증자와 해당 하는 ClusterRole 과 연결 해주는 역할을 한다.
• Role : User, Group, Service Account가 특정 Namespace 의 Resource 접근 및 권한 제어 설정을 할 수 있다.
• RoleBinding : 허가 된 인증자와 해당 하는 Role 과 연결 해주는 역할을 한다.

위 그림을 통하여 앞서 말한 4 가지의 기능을 설명 하겠다.

User, Group, Service Account에서 Kubernetes Cluster 로 접근 한다.

[ClusterRole]

ClusterRolebinding 은 User 와 Group 에 대해 지정된 ClusterRole 과 연결 시켜 주는 역할을 한다. ClusterRole 은 그림에서 존재하는 모든 Namespace(1, 2) 의 Pod Resource에 대한 watch, get, list 권한을 설정 했다. 또한 Service Resource 에는 get, list 에 대한 권한을 설정 했다.

인증 된 사용자는 모든 Namespace 에서 Pod(watch, get, list), Service(get, list)에 명시한 작업이 가능하다.

[Role]

그 아래의 RoleBinding 1 은 Namespace 2 전용 Role 1 과 연결 한다. Role 1 은 Pod Resource 에 대한 create, watch, get, list, delete 사용 권한을 설정 했다. Service Resource 에는 get, list 사용 권한을 설정 했다.

RoleBinding 2 는 Namespace 1 전용 Role 2 와 연결 해준다. Role 2 는 Pod Resource 에 사용하려는 권한을 create, watch, get, list, delete 설정 했다. Service Resource 에는 create, delete 권한을 설정 했다.

인증된 User, Group, Service Account 는 특정 RoleBinding(1,2) 을 통해 특정 Namespace(1,2) 에서만 정해진 Role(1,2) 에 명시한 작업만을 할 수 있다.

두 기능의 차이는 “특정 Namespace 로 명시 되었는가? 아니면 모든 Namespace 에서 작업이 명시 되었는가?” 로 나누어 볼 수 있다.

RBAC 기능은 Kubectl 명령어로 바로 생성 할 수 있으며, 아래와 같이 yaml 파일 형식으로 ClusterRole 과 Role 에 필요한 내용을 작성하여, 상황에 맞게 구성을 할 수 있다.

ClusterRole / ClusterRolebinding 기본 구성

Role / RoleBinding 기본 구성

2. kubeconfig

RBAC 는 필요한 Resource 에 필요한 권한을 정의를 한다면, kubeconfig 는 Kubernetes API Server 접근에 필요한 인증 파일이다.

일반적으로 Kubernetes 사용자는 Kubernetes 설치 시점에 OS 계정 root 또는 root의 권한과 동일한 계정으로 설치하기에, 해당 계정에서만 동작 한다고 생각 할 수 있다. OS 계정이 아닌, “kubectl” 명령어, API 를 통하여 인증 정보를 확인하고 동작한다.

“Kubeconfig 파일이 왜 존재하는가?”

Kubernetes 내의 서비스에 접근 하려면 어떤 방법이 있을까?

Kubectl 명령어를 활용하여 어떤 Kubernetes (cluster) 에 어떤 관계를 가진(context) 접근하려는 인증 받은 사용자(Users)를 일일이 명시하여 사용 할 수 있다.

매번 해당 방법으로 수행 할 경우, 복잡하여 실수 빈도와 사용하기에 어려운 점이 발생 할 수 있다.  정보를 미리 등록하여 손쉽게 사용할 수 있도록 한 것이 kubeconfig 파일이다.

Kubeconfig 역할은 하나의 Cluster, Context, User 로 구성 된 환경, 여러 Cluster 환경을 하나의 그룹으로 묶어 편리하게 관리 및 사용 할 수 있다.

2.1 kubeconfig 파일 구성

Kubeconfig 파일은 크게 3개의 구성으로 나누어 볼 수 있다.

1. clusters
– 접속 대상인 Kubernetes Cluster 정보들을 저장한다.
– Node 의 IP, Port 등 서버의 정보들을 정의한다.
2. contexts
– User 와 Cluster 간 관계를 저장한다.
3. users
– Cluster 에 접속하려는 user 정보를 저장한다.
– 여러 User 와 Cluster 가 있을 수 있으며, 각각 접근에 대한 정보를 정의한다.
– Client-certificate : Client 인증서 ctr 파일 정보
– Client-key : Client key 파일 정보

아래의 그림과 같이 하나의 Cluster 가 아닌 여러 Cluster 들을 하나의 kubeconfig 파일로 묶을 수 있으며, 인증 된 사용자는 Kubernetes Cluster 에 접근 할 수 있다.

2.2 Kubernetes 인증 순서

Kubeconfig 와 RBAC 가 구성 된 환경에서 인증 절차는 아래와 같은 순서로 동작하게 된다.

1)  User, Group, Service 는 Kubernetes 서비스에 접근/작업 요청을 kubectl (API) 명령어를 통하여 전달하게 된다.

2)  Kubernetes 내 정식 등록 된 사용자 또는 Service 인지, 인증 절차(Authentication)를 진행 하게 된다. 인증 확인이 되면 다음 단계로 넘어간다.

3)  요청자에게 부여된 Role(RBAC) 에 대한 작업 권한 확인(Authorization)이 되면 다음 단계로 넘어 간다.

4)  요청 내용이 올바른 형식인지 확인 한다. (Admission Control)

5)  형식이 맞지 않게 되면, 요청을 거부한다.

6)  요청에 대해 승인이 되면, 요청 내용에 대한 Resource 접근 및 요청 내용을 수행하게 된다.

3. 테스트 시나리오 검증 – OS 계정 별 권한 부여

위에서 설명한 RBAC 와 kubeconfig 를 활용하여 테스트 시나리오의 OS 계정에도 Kubernetes 접근 사용자마다 다른 접근 / 권한 부여를 해보았다. Kubernetes 내의 모든 Cluster 에 사용 가능한 User 가 아닌, 사용이 필요한 Resource 에 대해 최소한(필요한) 만큼만의 권한을 주는 방법이다.

[테스트 시나리오]

–   OS 계정 test-viewer 와 score 에 각각 K8S 사용 권한 요청을 받았다.

–   test-viewer 계정은 해당 K8S Cluster 에서 있는 pod, deployment 에 대해 보기 권한.

–   test-viewer 계정으로 작업 가능한 일수는 10일.

–   score 계정은 K8S 의 namespace 중 score 에서만 pod / deployment 등 생성, 삭제, 보기 등 모든 작업 요청.

–   score 계정으로 작업 가능 일수는 1일

테스트 시나리오를 그림으로 그려본다면 위와 같으며,

OS User test-viewer 계정은 ClusterRole 을 사용하여 Kubernetes 의 해당 Cluster 모든 Namespace 에서 pod 와 Deployment Resource 에 대한 get, list 권한을 10일 동안 사용 가능 하도록 설정이 필요하다.

OS User score 계정은 Role 을 사용하여 score 라는 특정 Namespace 에서 생성, 삭제, 보기 등 모든 권한을 1일 동안 사용 가능 하도록 설정을 해야 한다.

[Role /RoleBinding 적용]

1) 시스템의 /home 디렉토리에 user 및 home 디렉토리 유무 확인

2) Openssl 사용자 인증서 확인

3) CertificateSigningRequest 생성

4) CertificateSigningRequest 승인

5) Certificate 인증서 생성

6) Context생성

7) Role/Rolebeinding생성

8) Config 설정

9) kube-admin context 삭제 및 user 삭제

– 각 계정에 부여할 인증서 만료 기간을 확인 할 수 있다.

“REQUESTEDDURATION” 은 Kubernetes 에 적용 된 시점부터 시간을 check 한다.

예를 들어 2024-08-27 13:00:00 에 csr 이 등록 되었다면 2024-08-28 13:00:00 시간이 되어야 하루가 지나게 된다.

[ClusterRole 테스트 확인]

pod / deployment 는 정상적으로 출력한다.

그 외 resource 들에 대해서는 권한이 없어 출력 할 수 없다.

[Role 테스트 확인]
score namespace 에서 pod, deployment resource 생성은 정상적으로 된다. 그 외 namespace resource 는 출력하지 않는다.

[인증서 만료]

마치며

Kubernetes 에서 지원되는 기능을 활용하여 OS 계정 별 권한을 어떻게 주면 좋을지 생각 해보았다.

위 방법보다 더 쉽고 간편하게 설정 하는 방법이 있을 수 있다. kubeconfig 를 활용하여 context에 비밀번호를 입력하도록 하여 더 보안에 강화를 할 수 도 있다.