이쿠의 슬기로운 개발생활

함께 성장하기 위한 보안 개발자 EverNote 내용 공유

Kubernetes/Kubernetes 이론

Admission Controller

이쿠우우 2020. 11. 5. 19:16
반응형

 

 

 

Kubernetes Admission Controller


[Admission Controller 관련 글목록]

Kubernetes Version 1.18 에 해당함.

Kubernetes Admission Controller
Mutating Admission Controller 생성해보기
Validating Admission Controller


 

 

Admission Controller란?

 

Admission Controller는 각종 Object(Pod, volume, service등)를 생성하기 위해

Kube-apiserver 모듈로 Request를 보낼 시

해당 Request 내용을 변형, 검증할 수 있는 Plugin의 집합임.

관리자가 plugin을 개발해서 추가할 수도 있음.

 

Admission Controller는

Compiled-in Admission Controller와

Custom Admission Controller

로 2가지 종류가 있음.

 

그리고 해당 2가지 종류의 Admission Controller는

kube-apiserver follow의 단계 중 

Mutating admission와 Validating admission

2가지의 hook point를 통해 동작됨.

 

먼저 Compiled-in Admission Controller, Custom Admission Controller 에 대해 자세히 설명함.

 

Compiled-in Admission Controller(Interneal Admission Webhook)

kube-apiserver에 complie되어서 존재하고 있는 admission controller임.

사용자(관리자)가 별도의 webhook server를 구현하여 통신할 필요없이 

kube-apiserver에서 admission controller를 활성화하는 것으로 동작이 가능함.

ex) DefaultIngressClass, NamespaceExists Admission Controller, ServiceAccount Admission Controller

 

Custom Admission Controller(Externeal Admission Webhook)

kube-apiserver 외부에서 동작하는 admission controller로

사용자(관리자)가 별도의 webhook server를 구현하여

kube-apiserver가 해당 webhook server와 통신하며 동작함.

ex) MutatingAdmissionWebhook, ValidatingAdmissionWebhook, imagePolicyWebhook

 

kubernetes version 1.7 이전에는 Admission Controller를 추가하기 위해

kube-apiserver 코드를 직접 수정하고 다시 컴파일을 했어야 가능했음.

하지만 1.17 이후부터는 이러한 번거롭고 어려운 작업을 대체하기 위해 

Externeal Admission Webhook 기능을 추가해서 컴파일 없이

Webhook Server를 통해 plugin을 연동하면 

Admission Controller 기능이 수행 되도록 Update를 했음

이후 1.18 version 부터는 Externeal Admission Webhook이 세분화 되어

mutating, validating Admission Controller로 나누어서 관리할 수 있게됨.

이러한 Webhook admission controller를 통해 

개발자는 본인이 필요한 webhook server를 만들어서 

Admission Controller에 plugin형식으로 적용해서 사용할 수 있음.

 

 


Admission Controller가 사용하는 2개의 hook point 확인

 

Admission controller설명하기 위해서는 

기초개념으로 Kubernetes module 중 kube-api-server에 Pod 등 각종 object 생성 요청이 왔을 때의

Follow chart를 알아야함.

 

kube-apiserver follow 알아보기

[kube-apiserver follow chart]

 

 

1. API HTTP handler

Kubernetes 관리자가 kubectl tool로 

apply 혹은 create 명령을 통해서 Pod 등 각종 object 생성 요청을 하게되면

바로 kube-apiserver로 해당 요청이 전달되는데

이 요청은 모두 HTTP 형식으로 전달됨.

kube-apiserver는 HTTP Request를 받아서

요청을 처리하기 위한 작업을 시작함.

 

2. Authentication Authorization

가장 먼저 인증과 권한을 확인함.

kubectl 명령으로 kube-apiserver에 접근하기 위해

kubeconfig 파일에 설정된 인증 방식으로 

kube-apiserver에 접근을 시도하는데

이때 사용되는 인증 방식으로 JWT, TLS 등등이 있음.

이 것을 검증하고

또 권한확인을 위해 RBAC 즉 clusterRole 혹은 Role을 확인하게 되는데

이런 과정을 검증하는 단계가 바로 Authentication Authorization 단계임.

[참고 글]

Kubernetes 인증(Authentication) 이론


 

3. Mutating admission (Admission Controller)

Hook point

해당 단계는 Admission Controller에 속하는 단계로

Http Request(yaml 혹은 json 형식)를 검사한뒤 적절한 값으로 변경할 수 있음.

Request를 중간에 가로채서 관리자가 생성한

webhook server로 보낸 뒤 webhook server에서 관리자가 원하는 검증을 수행하고 

webhook server가 request를 변경해서 respone을 보낼수도 있음.

즉 Mutating 단계를 통해 request data를 변경할 수 있음.

 

4. Object Schema Validation

request에 형식이 올바른지 확인하는 단계.

필수 data가 정상적으로 들어가 있는지 오타는 없는지,

name에 설정된 값이 규칙에 따라 올바르게 입력됐는지 확인함.

yaml 파일 형식이 올바른지 확인하는 단계라고 보면 됨.

 

5. Validating admission (Admission Controller)

Hook point

해당 단계 또한 Admission Controller에 속하는 단계임.

Request(yaml 혹은 json 형식)가 생성될 수 있는지 확인하는 단계.

예를 들어 namespace에 Pod, service등 각종 object를 생성하기 전에

해당 namespace에 동일한 object가 이미 있는지 확인하거나

관리자가 직접 webhook server를 구현해서 

체크하고 싶은 부분을 추가할 수 있음.

 

6. Persisted to etcd

상위의 모든 단계를 통화하면 정상적인 Request data로 확인하고

etcd database에 내용을 저장함.

etcd에 request data가 저장되어 있으면

이후에 kube-controller, scheduler 모듈이

이를 확인하고 대응함.

 

이와같이 관리자가 Pod와 같은 각종 Oject를 생성하면

단순하게 뿅하고 생성되는 것이 아니라 각종 검증단계를 거쳐서 생성되게 되고 

최종적으로 etcd에 생성정보를 저장하게 됨.

알아보고자 하는 Admission Controller도 위에서 설명한 과정에 속하게 되는데

Admission Controller에 해당하는 단계가 바로 Mutating admission와 Validating admission 임.

admission controller 종류인 

Compiled-in Admission Controller와

Custom Admission Controller

모두 상위에서 설명한 2개의 hook point를 기반으로 동작함.

특정 admission controller는 mutating admission hook point만 사용할 수도 있고

validating admission controller만 사용할 수도 있음.

또는 mutating, validating 2개의 hook point 모두를 사용해서 동작할 수도 있음.

 

 

 

Mutating Admission hook point 을 사용하는 admission controller

mutating(변경)

Kube-apiserver로 온 Request를 변경할 수 있음

해당 mutating hook point를 사용하는 예제와

admission controller를 알아보겠음.

 

[사용 예시]

모든 Pod가 생성될 때 특정 Container를 무조건 추가해서 배포되도록 하거나

volume를 추가할 수도 있음.

또는 labels를 강제(자동)로 추가할 수도 있음.

 

[Compiled-in Admission Controller]

DefaultIngressClass

SecurityContextDeny

등등

 

[Custom Admission Controller]

MutatingAdmissionWebhook

 

 

Validating  Admission hook point 을 사용하는 admission controller

validating(유효성검증)

Kube-apiserver로 온 Request(yaml 혹은 json 형식)가 

생성될 수 있는지 확인하는 단계.

해당 mutating hook point를 사용하는 예제와

admission controller를 알아보겠음.

 

[사용 예시]

pod를 생성할 때 privileged 권한을 가지고 있으면

host의 커널 자원에 접근할 수가 있어서 보안상 굉장히 취약해짐

악의적인 사용자가 고의로 privileged 권한을 가진 Pod를 배포해서

해당 Pod를 통해 host를 공격할 수도 있음.

그래서 Pod를 생성할 때 privileged 권한을 가지고 있으면

Pod 생성이 안되게 막아야 하는데 

이런 역할을 수행할 수 있는 단계가 validating Admission 단계임

 

[Compiled-in Admission Controller]

NamespaceExists

PodSecurityPolicy

등등

 

[Custom Admission Controller]

ValidatingAdmissionWebhook

 

Mutating, Validating Admission hook point를 모두 사용하는 admission controller

 

[Compiled-in Admission Controller]

ServiceAccount

등등

 

[Custom Admission Controller]

개발자가 

MutatingAdmissionWebhook, ValidatingAdmissionWebhook

모두 사용하는 webhook을 만들면 됨.

 

 


 

 

kube-apiserver 명령 사용법

아래와 같이 kubernetes 공식 page의 글을보면

kube-apiserver -h, kube-apiserver -v 등

kube-apiserver 명령을 사용하라고 하는데

해당 명령을 master 혹은 worker node의 host에서 사용하면

해당 명령을 찾을 수 없다고 나옴.

그렇다고 yum 혹은 apt로 설치를 할려고 해도 해당 명령이 없음

 

kube-apiserver 명령을 사용하는 방법은

kube-apiserver container에 안에서 사용해야함

 

1. kube-apiserver pod를 조회함

[명령어]

kubectl get pod -n kube-system 

 

2. kube-apiserver pod 안으로 접속

[명령어]

kubectl -exec -it [상위에서 찾은 kube-apiserver pod name] -n kube-system  -- /bin/sh

 

3. kube-apiserver 명령 사용

 

[kube-apiserver 명령 옵션 참고]

https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/

 

 


 

 

Default로 실행되고 있는 Admission Controller Plugin종류

 

[명령어]

kube-apiserver -h | grep enable-admission-plugins

 

[결과]

kubernetes version 1.18.8의 경우

default로 실행되고 있는 admission controller는 아래와 같음

NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota

 

 


 

 

Admission Controller Plugin 추가 및 실행(enable)

 

첫번째 방법 : kube-apiserver 명령 사용

 

kube-apiserver container에 들어가서 아래의 명령을 실행

[명령어]

kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger ...

 

두번째 방법 : kube-apiserver.yaml 파일 사용

 

첫번째 방법보다는 복잡하지만

이렇게도 사용할 수 있다는 것을 알려드리기 위해 설명.

PodSecurityPolicy를 Admission controller 추가하는것을 예로 설명

 

[kube-apiserver.yaml 로 이동]

해당 파일 경로 (default의 경우) : /etc/kubernetes/manifests

 

[kube-apiserver.yaml 에 설정 추가]

(Default 상태)

- --enable-admission-plugins=NodeRestriction

기존에는 

 

(Pod Security Policy 추가 )

- --enable-admission-plugins=NodeRestriction,PodSecurityPolicy

 

 

이제 admission Controller에 PSP를 활성화 적용함

 

[ 명령어 ]

kubectl apply -f kube-apiserver.yaml

 

[ 생성 확인 ]

(명령어)

kubectl get podl -n kube-system

kube-apiserver-kube.master.node Pod 가 있는지 확인

 

(명령어)

kubectl describe pod kube-apiserver-kube.master.node -n kube-system

 

설정 중

- --enable-admission-plugins=NodeRestriction,PodSecurityPolicy

이 정상적으로 추가되어있는지 확인.

 

 

 


 

 

Admission Controller Plugin 종료 (disable)

 

첫번째 방법 : kube-apiserver 명령 사용

 

kube-apiserver container에 들어가서 아래의 명령을 실행

[명령어]

kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ...

 

 

두번째 방법 : kube-apiserver.yaml 파일 사용

 

첫번째 방법보다는 복잡하지만

이렇게도 사용할 수 있다는 것을 알려드리기 위해 설명.

PodSecurityPolicy를 Admission controller 제거하는것을 예로 설명

 

[kube-apiserver.yaml 로 이동]

해당 파일 경로 (default의 경우) : /etc/kubernetes/manifests

 

[kube-apiserver.yaml 에 설정 제거]

(기존 PodSecurityPolicy가 추가되어있는 상태)

- --enable-admission-plugins=NodeRestriction,PodSecurityPolicy

 

(Pod Security Policy 제거)

- --enable-admission-plugins=NodeRestriction

 

설정 적용

 

[ 명령어 ]

kubectl apply -f kube-apiserver.yaml

 

[ kube-apiserver pod 재생성 확인 ]

(명령어)

kubectl get podl -n kube-system

kube-apiserver-kube.master.node Pod 가 있는지 확인

 

(명령어)

kubectl describe pod kube-apiserver-kube.master.node -n kube-system

 

설정 중

- --enable-admission-plugins=NodeRestriction

PodSecurityPolicy가 정상적으로 제거되어있는지 확인.

 

 

 

 

 

 


제 글을 복사할 시 출처를 명시해주세요.
글에 오타, 오류가 있다면 댓글로 알려주세요! 바로 수정하겠습니다!


 

 

 

참고

[admission controller]

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

https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/

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

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

https://m.blog.naver.com/PostView.nhn?blogId=alice_k106&logNo=221546328906&proxyReferer=https:%2F%2Fwww.google.com%2F

https://ddii.dev/kubernetes/mutating-web-hook/#

https://woohhan.tistory.com/44

https://ssup2.github.io/theory_analysis/Kubernetes_Admission_Controller/

 

 

 

반응형

'Kubernetes > Kubernetes 이론' 카테고리의 다른 글

Validating Admission Controller  (0) 2020.11.05
Mutating Admission Controller  (0) 2020.11.05
Pod Security Policy (PSP)  (2) 2020.09.20
Security Context  (0) 2020.09.20
Privileged Container  (0) 2020.09.20