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/
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 |