Admission Control

 Kubernetes에서 kubelet, 혹은 kubectl을 통해 api server에 요청을 보내면 api server는 controller plane의 컴포넌트들과 상호작용을 완료한 후 요청에 대해 응답한다. 

 

 이 요청이 일어날 때, 아무 요청이나 받아들이면 클러스터는 금새 잘못된 요청, 악의적인 요청들로 인해 망가질 가능성이 있다. 따라서 요청 자체가 올바른 지 판단하는 과정이 필요하다.

 

 이번 포스팅에서 api 요청이 "올바르다"고 판단하는 기준이 무엇일지 알아본다.

 

API Request 과정

 

api server로 요청이 들어오게 되면 아래 3가지 절차에 의해서 이 요청을 확인한다.

 

1. 요청이 올바른 대상으로 부터 왔는가 (Verification)

2. 요청을 하는 대상에게 충분한 권한이 있는가 (Validation)

3. 요청 내용이 올바른가 (Admission Control)

 

 Verification은 kubectl 명령을 사용하거나 kubelet이 요청을 보낼 때 포함하는 auth key 값을 확인하는 과정을 의미한다. 보통 /etc/kubernetes/admin.conf 와 같은 위치에 적혀있는 user key 값에 해당하는 내용으로, kubeadm 같은 툴을 이용해서 클러스터를 만들 경우 정상 명령으로 식별할 수 있도록 해당 키를 클러스터에 추가하는 과정을 거친다 (클러스터 생성 이후에도 추가할 수 있다). 만약 이 과정에서 미식별된 키로 명령을 요청하게 되면 api server가 Forbidden 을 반환한다.

 

 Validation은 해당 사용자에 부여된 권한이 요청 작업을 수행하기에 충분한지 확인하는 과정이다. kubeadm 설정에 따라 여러 확인방법이 있을 수 있겠으나 기본적으로는 RBAC(Role Based Access Control) 을 통해서 권한을 부여하고 확인한다. 

 이 과정에서 사용되는 오브젝트가 Role, ClusterRole, RoleBinding, ClusterRoleBinding 등이다.

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

 

 위의 Verfication, Validation을 거친 후 마지막으로 진행하는 과정이 바로 Admission Control 과정이다. 이 과정은 요청의 Permission을 점검하는 과정이 아니라 요청 자체가 올바른지, 혹은 설정한 Admission Control에 따라 수정되어야 하는 내용은 없는지 확인하는 과정이다. 

 예를 들어서 Service를 생성했을 때 타입에 따라 특정 스펙(e.g. ExternalTrafficPolicy)은 사용할 수 없다거나, Annotation에 따라 IP를 특정값 내에서 사용하거나 하는 경우가 모두 Admission Control에 의해 이루어 진다고 볼 수 있다.

 

Admission Control 과정

API request 과정 (출처: https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/#what-are-kubernetes-admission-controllers)

Admission Control은 위 그림처럼 Authentication, Authorization 이후 Mutating Admission, Validating Admission 과정이 존재한다. 

 

 Mutating Admission

  들어온 요청을 Webhook으로 보내어 요청 사항을 필요하다면 변형(mutate)하는 과정이다.

 DefaultStorageClass 가 대표적인 예 중 하나라고 할 수 있다. 어떤 StorageClass를 사용할 지 명시하지 않고 default로 명시하면 실제 StorageClass가 붙을 때 Default로 설정되어 있는 StorageClass로 자동 설정된다. 이처럼 Mutating Admission 과정에서는 들어온 요청에 대해서 임의로 변경을 가할 수 있는 과정이다.

 

 Validation Admission

  이 과정은 어떤 변형을 가하기 보다는 생성하거나 수정하려는 오브젝트가 사용하면 안되는 값을 사용하고 있는지를 체크하는 과정이다.

  LimitRange가 이 Admission의 대표적인 예다. LimitRange의 경우 운영자가 설정한 범위 밖의 리소스를 사용할 경우 Pod 생성을 할 수 없도록 막는다.

 

위의 과정을 모두 통과했을 때, 요청이 정상적으로 api server를 통과하여 etcd에 저장될 수 있다.

 

주요 Admission control

의외로 30가지 이상의 Admission Control이 이미 쿠버네티스 상에서 동작하고 있다. 이 중 운영 중에서 많이 접하게 되는 것들은 아래와 같은 것들이 있다.

 

DefaultIngressClass

  IngressClass가 미지정인 경우 default로 설정된 IngressClass를 지정한다.

 

DefaultStorageClass

  StorageClass가 미지정인 경우 default로 설정된 StorageClass를 지정한다.

 

LimitPodHardAntiAffinityTopology

  Pod에 AntiAffinity가 설정되어있을 경우 해당 케이스에 해당하는 Pod의 생성을 거부한다.

 

LimitRanger

  Namespace에 부여된 Resource보다 생성하고자 하는 Pod의 자원사용량이 많을 경우 생성을 거부한다.

 

PodSecurityPolicy

  SecurityPolicy를 기반으로 Pod가 생성 여부를 결정한다.

 

Priority

  priorityClassName을 확인해서 prioity 값을 수정한다.

 

ResourceQuota

  생성되는 개별 Pod들이 지정된 값을 넘어서 사용하는지 확인해서 생성 여부를 결정한다.

 

동작 중인 Admission Control들은 아래 링크에서 확인할 수 있다.

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