K8S 보안 "인증/인가"

개요

Kubernetes는 인증(Authentication)과 인가(Authorization)를 통해 보안을 관리할 수 있다.

인증은 User에 대한 접속 허가 여부를 결정하는 방식으로 일반적인 사용자의 ID/Password 기반 로그인을 의미한다.

인가는 인증이 완료된 사용자가 특정 리소스에 접근하여 특정 액션을 수행할 수 있는지 여부를 결정하는 방식으로 로그인 후 admin 관리메뉴에 접근할 수 있도록 허가할 것인지, 특정 네임스페이스에 접근할 수 있도록 할 것인지 등의 경우를 의미한다.

본문

Kubernetes에서는 인증은 User Object에 부여되며, 인가는 User, Group, Service Account에 각각 부여할 수 있다.

Kubernetes에서 의미하는 User, Group, Service Account는 다음과 같이 정의할 수 있다.

User

User는 일반적으로 생각하는 User의 Identity라고 볼 수 있다. 즉 ID가 바로 사용자가 되는 것이다. Kubernetes는 사용자 인증을 받기 위해 반드시 External IDP(Identity Provider)를 통해 인증받아야 하며, IDP 시스템과 통신하기 위해 OAuth Server를 통한 인증 토큰 발급 방식 또는 WebHook과 같은 연계 방식을 사용한다.

OAuth 인증의 경우 지원하는 별도의 서버를 구축하거나 기 구축되어 있는 인증 서버를 사용한다. WebHook을 통한 연계 방식은 대표적으로 GitHub, GitLab 연계 등이 있다. GitHub ID와 연계하여 시스템의 ID를 인증할 수 있다.

1) 클러스터 관리자는 Identity Provider를 통해 User의 인증 정보를 검증한다.

2) IDP를 통해 인증이 완료되면 Token 정보를 발급한다.

3) 클러스터 관리자는 해당 정보를 Service Account를 생성하여 Secret에 관리한다.

4) User는 대시보드에 로그인하거나, API 호출을 위해 인증을 시도한다. 이때 올바른 인증 정보를 입력했을 경우 API Server는 Secret을 확인하여 토큰 정보를 클라이언트에게 업데이트 한다. (kubeconfig update)

5) 이후 Client는 이 정보를 기반으로 API 호출을 진행한다.

Group

Group은 User의 모임이라고 할 수 있다. Group에 속한 User는 Group에 부여된 인가 방식을 공유할 수 있다.

Service Account

Service Account는 Kubernetes의 API를 호출하는 모든 행위에 대한 권한을 의미한다. API를 호출한다는 의미는 즉 Kubernetes의 Object를 컨트롤 할 수 있는 권한이 부여된다는 것과 동일한 의미로 해석할 수 있다.

대체로 Service Account는 User와 동일하게 Role을 부여 받을 수 있지만, 다음과 같은 차이가 있다.

비교 항목	User	Service Account
정의	API를 사용하는 User 즉 API를 사용하기 위한 그 인증 주체가 된다. 대체로 인증 주체를 사람으로 표현한다.	API를 사용하기 위한 인가 주체가 된다. 인증이 완료된 User가 Kubernetes Object를 컨트롤하기 위해 API를 호출하는 것으로, 대체로 인가 주체를 시스템으로 표현한다.
대상	User는 K8S 클러스터 내에 유니크하게 관리된다. 즉 User는 K8S 클러스터를 대상으로 한다.	Service Account는 Namespace 내에서 유니크하게 관리된다. 전체 Namespace에 모두 적용되는 Service Account의 경우 동일한 Name으로 모든 Namespace에 적용된다. 즉 적용 대상은 Namespace이다.
권한	User는 대체로 K8S 클러스터 전체를 대상으로 하는 포괄적인 권한을 관리한다. User는 사람을 주체로 하므로 권한을 관리자, 운영자, 배포관리자, 개발자 등 사람의 역할을 기준으로 분리한다.	Service Account는 Namespace 내의 K8S Object를 컨트롤하는 세분화된 권한을 관리한다. Service Account는 API를 호출하는 시스템을 주체로 하므로 권한을 K8S Object를 대상으로 분리한다. Object를 조회하고, 추가하고, 삭제하는 등의 권한이 부여된다.

인증

먼저 K8S에서 인증을 처리하는 절차에 대해 살펴보자.

1) ClusterAdmin은 User로 추가할 대상의 Identity를 검증하기 위해 IDP를 호출하여 ID/PW를 확인한다.

2) IDP는 인증을 확인하고 토큰을 발급한다.

3) ClusterAdmin은 Service Account를 생성한다. 이때 Service Account에는 Secret이 포함되며, 발급받은 Token을 적용하고 업데이트 한다.

4) User는 대시보드 로그인 시 IDP로 부터 인증 된 ID/PW로 로그인할 수 있다. 또는 API 호출을 위해 발급된 Token(kubeconfig)을 ClusterAdmin으로부터 제공받아 로그인할 수 있다.

5) API Server는 User의 로그인 토큰 또는 Identity 정보를 Secret으로 부터 검증하여 인증을 허가할지 여부를 결정한다.

인가

다음으로 인가 절차에 대해 살펴보자.

1) ClusterAdmin은 리소스(K8S Object + 물리노드) 권한을 부여하기 위한 기본 Role을 생성한다. 기본 생성되어 있는 Role과 신규 생성된 Role을 정의할 수 있으며, 하나 또는 하나 이상을 권한을 정의하는 보다 세분화된 형태로 Role을 생성한다.

2) 생성된 Role은 User, Group, Service Account에 부여하기 위해 RoleBinding을 사용하며 매핑한다. 앞서 정의한 바와 같이 Role을 Cluster 전반에 적용할 것인지 또는 Namespace 내에 정의할 것인지에 따라 User & Group 또는 Service Account를 선택하는 것을 권고한다.

3) 매핑된 Role에 의해 User, Group, Service Account는 리소스에 접근하여 Role을 수행한다. (API를 실행한다.)

결론

K8S에서 인증/인가는 안전한 API 서비스를 위해 반드시 거쳐야 할 중요한 설계 요소 중 하나이다. 사용자의 역할에 따라 User를 생성하고 K8S 리소스를 사용하기 위한 권한을 부여하여 안전한 Kubernetes 서비스를 제공하고, 외부로 부터 보호할 수 있도록 그 개념과 활용도를 고민하여 인증/인가 프로세스를 설계하도록 하자.

 

### 참고 사이트 ###

Using RBAC Authorization

https://kubernetes.io/docs/reference/access-authn-authz/rbac/

Using RBAC Authorization