📌 Mutating Admission Controllers

• 객체가 생성되기 전에 객체 자체를 변경하거나 변형할 수 있다.
• 요청을 변경할 수 있는 admission controller이다.
• NamespaceAutoProvision 플러그인이 대표적인 예시

📍Validating Admission Controllers

• 요청의 유효성을 검사하여 허용 또는 거부 할 수 있는 admission controller이다.
• NamespaceExists 플러그인이 대표적인 예시

이 두가지 유형의 컨트롤러 권한을 모두 사용가능한 컨트롤러가 있을 수 있다.

⚙️ MutatingAdmissionWebHook & ValidatingAdmissionWebHook

• 내장 되어 있는 admission controller 외에 외부에서 사용 가능한 특수한 컨트롤러
• 모든 요청이 admission controller 통과한 후 구성된 웹훅에 연결
• 웹훅에 도달하면 JSON 형식의 AdmissionReview 객체를 전달하여 AdmissionWebHookServer 호출
• 이 객체에는 요청을 한 사용자, 사용자가 수행하려는 작업 유형, 어떤 객체에 대한 세부 정보 등 요청에 대한 모든 세부 정보가 들어 있다.
• 요청을 받으면 AdmissionWebHookServer는 요청이 허용되는지 여부에 대한 결과가 포함된 AdmissionReview 객체로 응답
• 응답의 허용 필드가 true로 설정되어 있으면 요청이 허용, 오류로 설정되어 있으면 거부

🔨 How to create

• 먼저 자체 로직이 있는 AdmissionWebHookServer를 배포한 다음 웹훅 구성 객체를 생성하여 K8S에서 웹훅 구성해야함

1. Deploy Webhook Server

• 첫 번째는 자체 웹훅 서버를 배포하는 것

  Go 언어로 작성된 웹훅 서버 예제코드 : https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/webhook/main.go

• 모든 플랫폼에 구축할 수 있는 API 서버
• 유일한 요구 사항은 mutating & validating API를 수락하고 웹서버가 예상하는 JSON 객체로 응답해야 한다
• 로직을 갖춘 WebhookServer를 다른 서버에 배포하거나 컨테이너화 하여 K8S 클러스터 자체 내에 배포하도록 한다.
• K8S 클러스터에 Deployment로 배포된 경우, 액세스하려면 서비스가 필요 👉 Webhook-service라는 서비스도 존재

2. Configuring Admission Webhook

• 이 단계는 서비스에 연결하고 요청의 유효성을 검사하거나 변경하도록 클러스터 구성
• 이를 위해 ValidatingWebHookConfiguration Object(객체) 생성

# 웹훅 서버를 클러스터 내부가 아니라 외부에 자체적으로 배포한 경우 config
apiVersion: admissionregistration.k8s.io/v1 
kind: ValidatingWebhookConfiguration  // MutatingWebHookConfiguration으로 변경 사용 가능
metadata: 
  name: “pod-policy-example.com”

webhooks:

- name: “pod-policy-example.com”
  clientConfig: 
      url: “https://external-server.example.com”
  rules:

# 웹훅 서버를 K8S 클러스터 내부에 배포한 경우 config

apiVersion: admissionregistration.k8s.io/v1 
kind: ValidatingWebhookConfiguration  // MutatingWebHookConfiguration으로 변경 사용 가능
metadata: 
  name: “pod-policy-example.com”

webhooks:

- name: “pod-policy-example.com”
  clientConfig: 
      service:
        namespace: “webhook-namespace”
        name: “webhook-service”
      caBundle: “Ci0tLS0tQk…….tLS0K”
  rules:
    - apiGroups: [“”]
       apiVersions: [“v1”]
       operations: [“CREATE”]
       resources: [“pods”]
       scope:       “Namespaced”

• clientConfig : AdmissionWebHookServer의 위치를 구성하는 곳
  • 이 서버를 자체적으로 외부에 배포한 경우, 즉 K8S 클러스터 내 배포의 일부가 아닌 경우에 해당 서버의 URL 경로 제공 하면 됨
  • API 서버와 웹훅 서버 간의 통신은 TLS 서버를 통해 이루어져야 한다.
  • 따라서 인증서 번들을 구성해야 함
  • 서버는 한 쌍의 인증서로 구성해야함
  • caBundle을 생성하여 이 클라이언트 구성에 전달
• 다음으로 API 서버를 호출할 시기를 지정한다. (rule 필드)
  • 유효성 검사를 위해 웹훅 서버를 호출할 시점을 정확히 설정하는 규칙을 지정
  • 모든 호출에 이렇게 요청하는것은 바람직 하지 않다
  • 예를들어, pod를 생성하거나 삭제, deployment를 생성하는 등의 경우에만 호출되도록 할 수 있다.
  • apiGroups, apiVersions, operations, resources, scope 필드에서 이를 지정
  • 위 예시에선 pod를 생성하기 위해 호출할 때만 이 웹훅 구성을 호출한다!

💡 이 객체가 생성되면, 파드를 생성할 때마다 웹훅 서비스에 대한 호출이 이루어지고 응답에 따라 허용되거나 거부된다!