개요
Pod를 생성을 요청했을때의 전체 과정을 알아 본후
Admission Controller에 대하여 알아보겠습니다.
Pod 생성 과정
kubectl: 명령어 실행
Authentication : 사용자 인증, config 파일의 certificate를 사용하여 인증 합니다.
Authorization : 사용자의 권한 확인, Role를 통하여 검증 합니다.
AdmissionController : Authentication과 Authorization에서 하지 못한 제어를 추가 적으로 진행 합니다.
Admission Controller 개념
cluster 들어오는 요청을 처리하고, 해당 요청이 실제로 cluster에 적용되기 전에 추가적인 검증이나 수정 작업을 수행하는 중요한 구성 요소입니다. admission controller는 인증(Authentication)과 권한 부여(Authorization)를 통과한 후, 실제 resource가 생성되거나 수정되기 전에 개입하여 정책 준수 여부를 확인하거나 요청을 변경할 수 있습니다.
k8s에서 admssion controller는 기본적으로 켜져있습니다.
Admission Controllers의 역할
정책 적용
- 클러스터에 배포되는 리소스가 조직의 정책이나 보안 규정을 준수하는지 확인합니다.
- 예를 들어, 특정 네임스페이스에서만 특정 이미지를 사용하도록 제한하거나, Pod가 특정 리소스 요청을 초과하지 않도록 제한할 수 있습니다.
리소스 수정
- 요청된 리소스 객체를 수정하여 기본값을 설정하거나, 필요한 필드를 자동으로 추가할 수 있습니다.
- 예를 들어, 모든 Pod에 특정 라벨을 자동으로 추가하거나, 이미지 풀 정책을 설정할 수 있습니다.
보안 강화
- 악의적인 요청을 차단하거나, 보안 설정이 제대로 되어 있는지 확인하여 클러스터의 보안을 강화합니다.
- 예를 들어, PodSecurityPolicy를 사용하여 Pod의 보안 컨텍스트를 강제할 수 있습니다.
메트릭 및 로깅
- 요청에 대한 메트릭을 수집하거나, 로깅을 통해 클러스터 활동을 모니터링할 수 있습니다.
- 이를 통해 클러스터의 상태를 파악하고, 문제 발생 시 빠르게 대응할 수 있습니다.
Admission Controllers의 동작 방식
- 클라이언트 요청: 사용자가 kubectl이나 다른 도구를 통해 Kubernetes API 서버에 리소스 생성/수정 요청을 보냅니다.
- 인증(Authentication): API 서버는 요청자의 신원을 확인합니다.
- 권한 부여(Authorization): 요청자가 해당 작업을 수행할 권한이 있는지 검증합니다.
- admission controller 실행: 요청이 인증 및 권한 부여를 통과하면, adminssion controller가 요청을 검토하고 필요한 작업을 수행합니다.
- resource 저장: admisson controller가 요청을 승인하면, resource etcd에 저장되고 cluster에 적용됩니다.
Admission Controllers의 종류
Validating Admission Controllers
- 요청이 cluster정책을 준수하는지 검증하고, 조건에 맞지 않으면 요청을 거부합니다.
Mutating Admission Controllers:
- 요청된 resource객체를 수정하여 클러스터의 정책에 맞게 변경합니다.
주요 Admission Controllers 예시
NamespaceLifecycle
- 네임스페이스의 생성 및 삭제 과정에서 리소스의 생명주기를 관리합니다.
LimitRanger
- 리소스에 대한 리밋(제한)을 적용하여, 네임스페이스 내의 리소스가 지정된 제한을 초과하지 않도록 합니다.
ServiceAccount
- Pod에 서비스 어카운트를 자동으로 할당하여, Pod가 클러스터 내에서 적절한 권한을 가지도록 합니다.
DefaultStorageClass
- PVC(PersistentVolumeClaim)에 기본 스토리지 클래스를 자동으로 지정합니다.
PodSecurityPolicy
- Pod가 실행될 때 보안 컨텍스트를 검증하고, 보안 정책을 강제합니다.
Admission Controllers의 역할
- 정책 적용:
- 클러스터에 배포되는 리소스가 조직의 정책이나 보안 규정을 준수하는지 확인합니다.
- 예를 들어, 특정 네임스페이스에서만 특정 이미지를 사용하도록 제한하거나, Pod가 특정 리소스 요청을 초과하지 않도록 제한할 수 있습니다.
- 리소스 수정:
- 요청된 리소스 객체를 수정하여 기본값을 설정하거나, 필요한 필드를 자동으로 추가할 수 있습니다.
- 예를 들어, 모든 Pod에 특정 라벨을 자동으로 추가하거나, 이미지 풀 정책을 설정할 수 있습니다.
- 보안 강화:
- 악의적인 요청을 차단하거나, 보안 설정이 제대로 되어 있는지 확인하여 클러스터의 보안을 강화합니다.
- 예를 들어, PodSecurityPolicy를 사용하여 Pod의 보안 컨텍스트를 강제할 수 있습니다.
- 메트릭 및 로깅:
- 요청에 대한 메트릭을 수집하거나, 로깅을 통해 클러스터 활동을 모니터링할 수 있습니다.
- 이를 통해 클러스터의 상태를 파악하고, 문제 발생 시 빠르게 대응할 수 있습니다.
Admission Controllers의 동작 방식
- 요청 처리 흐름:
- 클라이언트 요청: 사용자가 kubectl이나 다른 도구를 통해 Kubernetes API 서버에 리소스 생성/수정 요청을 보냅니다.
- 인증(Authentication): API 서버는 요청자의 신원을 확인합니다.
- 권한 부여(Authorization): 요청자가 해당 작업을 수행할 권한이 있는지 검증합니다.
- admission controller 실행: 요청이 인증 및 권한 부여를 통과하면, 어드미션 컨트롤러가 요청을 검토하고 필요한 작업을 수행합니다.
- 리소스 저장: 어드미션 컨트롤러가 요청을 승인하면, 리소스가 etcd에 저장되고 클러스터에 적용됩니다.
- admission controller 의 종류:
- Validating Admission Controllers: 요청이 클러스터 정책을 준수하는지 검증하고, 조건에 따라 허가 또는 거부 합니다.
- Mutating Admission Controllers: 요청된 리소스 객체를 수정하여 클러스터의 정책에 맞게 변경합니다.
주요 Admission Controllers 예시
admision contoller 전체 확인 방법
enabled된 admission controller 확인 방법
kubectl exec kube-apiserver-controlplnae -n kube-system --kube-apiserver -h | grep enable-admission-plugins
주요 예시
- NamespaceLifecycle:
- 네임스페이스의 생성 및 삭제 과정에서 리소스의 생명주기를 관리합니다.
- LimitRanger:
- 리소스에 대한 리밋(제한)을 적용하여, 네임스페이스 내의 리소스가 지정된 제한을 초과하지 않도록 합니다.
- ServiceAccount:
- Pod에 서비스 어카운트를 자동으로 할당하여, Pod가 클러스터 내에서 적절한 권한을 가지도록 합니다.
- DefaultStorageClass:
- PVC(PersistentVolumeClaim)에 기본 스토리지 클래스를 자동으로 지정합니다.
- PodSecurityPolicy:
- Pod가 실행될 때 보안 컨텍스트를 검증하고, 보안 정책을 강제합니다.
Admission Controllers 설정 방법
Kubernetes API 서버는 여러 어드미션 컨트롤러를 지원하며, 필요에 따라 활성화(enable)하거나 비활성화(disable)할 수 있습니다.
API server 시작 시 --enable-admission-plugins 플래그를 사용하여 필요한 admission controller를 활성화 하여 지정할 수 있습니다.
API server 시작 시 --disable-admission-plugins 플래그를 사용하여 필요한 admission controller를 비활성화 하여 지정할 수 있습니다.
아래는 2가지 방식의 설정 방식 입니다.
admission controller의 webhook
개념
Kubernetes의 Admission Controller Webhook은 클러스터에 들어오는 API 요청을 가로채어 추가적인 검증 또는 변경 작업을 수행하는 확장 가능한 메커니즘입니다. 이를 통해 cluster 관리자나 개발자는 custom logic을 적용하여 cluster의 보안, 정책 준수, 리소스 관리 등을 세밀하게 제어할 수 있습니다.
Admission Controller Webhook은 주로 Mutating Webhook과 Validating Webhook 두 가지 유형으로 나뉩니다.
Mutating Webhook (변경 웹훅)
- 역할: API 요청을 변경하거나 수정할 수 있습니다.
- 예시
- 특정 라벨을 자동으로 추가하거나 기본값을 설정하는 등의 작업을 수행합니다.
- 모든 Pod에 특정 사이드카 컨테이너를 자동으로 추가
- 리소스 요청/제한을 자동으로 설정
Validating Webhook (검증 웹훅)
- 역할: API 요청의 유효성을 검사하고, 정책에 맞지 않으면 요청을 거부합니다. 이는 보안 강화와 정책 준수를 보장하는 데 사용됩니다.
- 예시
- 특정 네임스페이스에서만 특정 리소스를 생성할 수 있도록 제한
- 이미지 레지스트리를 검증하여 신뢰할 수 없는 이미지의 사용을 방지
Admission Controller Webhook의 동작 방식
- API 요청 수신:
- 사용자가 kubectl이나 다른 클라이언트를 통해 Kubernetes API 서버에 리소스 생성, 업데이트, 삭제 등의 요청을 보냅니다.
- Authentication & Authorization:
- API 서버는 먼저 요청을 인증(Authentication)하고 권한 부여(Authorization)를 수행합니다.
- Mutating Webhook 호출:
- 순서: 먼저 Mutating Webhook이 호출됩니다.
- 작동: 요청을 필요에 따라 변경합니다. 여러 Mutating Webhook이 설정된 경우, 순차적으로 호출되어 각 웹훅이 요청을 수정할 수 있습니다.
- 예시: Pod 생성 요청 시, 사이드카 컨테이너를 추가하는 Mutating Webhook이 요청을 수정할 수 있습니다.
- Validating Webhook 호출:
- 순서: Mutating Webhook이 모두 실행된 후, Validating Webhook이 호출됩니다.
- 작동: 최종 수정된 요청을 검증하여 정책에 부합하는지 확인합니다. Validating Webhook은 요청을 승인하거나 거부할 수 있습니다.
- 예시: Pod 생성 요청이 특정 라벨을 포함하고 있는지 검증하거나, 리소스 사용량이 정책을 초과하지 않는지 확인할 수 있습니다.
- 응답 처리:
- 모든 Webhook을 통과한 요청은 실제로 클러스터에 반영됩니다. 거부된 요청은 클라이언트에게 오류 메시지와 함께 반환됩니다.
추가 : admission controller와 webhook 둘중 어느게 먼저 실행되는가?
--enable-admission-plugins 에 정의된 순서대로 시작이 됩니다. 그러나 기본 설정에서는 내장 Admission Controllers가 먼저 호출되고, 그 다음에 Webhook Admission Controllers가 호출됩니다.
--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota,MutatingAdmissionWebhook,ValidatingAdmissionWebhook
Admission Controller Webhook의 생성 방법
1. webhook server배포
아래와 같은 코드를 가진 server를 배포하고 , reponse의 "allowed" 필드에 값에 따라 api 요청이 "허가" 또는 "거부"가 됩니다.
2. webhook configurateion 배포
rule에 배칭이되면 webhook-service로 api 요청 정보를 보내고 결과 따라 api 요청이 허용 또는 거부 됩니다.
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
name: example-validating-webhook
webhooks:
- name: validate.example.com
clientConfig:
service:
name: webhook-service
namespace: default
path: "/validate"
caBundle: <base64-encoded-CA-cert>
rules:
- operations: ["CREATE", "UPDATE"]
apiGroups: ["apps"]
apiVersions: ["v1"]
resources: ["deployments"]
admissionReviewVersions: ["v1"]
sideEffects: None
정리
- Admission Controllers는 Kubernetes cluster 들어오는 요청을 검증하고 수정하여 정책 준수와 보안을 강화합니다.
- Validating과 Mutating 두 가지 유형이 있으며, 각각 요청의 검증과 수정 역할을 수행합니다.
- 다양한 admission controller를 통해 cluster의 다양한 요구사항과 정책을 충족시킬 수 있습니다.
- API server 설정을 통해 필요한 admission controller를 활성화하거나 비활성화할 수 있습니다.
- admission controller webhook를 통하여 사용자가 api 요청에대한 제어를 할 수 있습니다.
'Cloud > k8s-CKAD' 카테고리의 다른 글
[CKAD] Custom Resource Definitions(CRD) (1) | 2024.10.29 |
---|---|
[CKAD] k8s API 버전 체계 (0) | 2024.10.17 |
[CKAD] Statefulset 과 Headless Service (0) | 2024.10.09 |
[CKAD] Network Policy (0) | 2024.10.03 |
[CKAD] service (0) | 2024.09.16 |