4.7.2. Admission Webhooks

OpenShift Container Platform에서는 API 승인 체인 중에 웹 후크 서버를 호출하는 승인 Webhook 오브젝트를 사용할 수 있습니다.

다음 두 가지 유형의 승인 Webhook 오브젝트를 구성할 수 있습니다.

승인 Webhook 변경을 사용하면 리소스 콘텐츠가 지속되기 전에 변경 웹 후크를 사용하여 리소스 콘텐츠를 수정할 수 있습니다.
승인 Webhook를 검증 하면 웹 후크를 검증하여 사용자 정의 승인 정책을 적용할 수 있습니다.

웹 후크 및 외부 웹 후크 서버를 구성하는 것은 이 문서의 범위를 벗어납니다. 그러나 OpenShift Container Platform에서 제대로 작동하려면 Webhook가 인터페이스를 준수해야 합니다.

중요

승인 Webhook 는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

오브젝트가 인스턴스화되면 OpenShift Container Platform은 API 호출을 수행하여 오브젝트를 허용합니다. 승인 프로세스 중에 승인 컨트롤러는 Webhook 를 호출하여 선호도 레이블 삽입과 같은 작업을 수행할 수 있습니다. 승인 프로세스가 끝나면 검증 승인 컨트롤러에서 Webhook를 호출하여 선호도 레이블 확인과 같은 오브젝트가 올바르게 구성되었는지 확인할 수 있습니다. 검증이 통과되면 OpenShift Container Platform에서 구성된 대로 오브젝트를 스케줄링합니다.

API 요청이 도착하면 변경 또는 검증 승인 컨트롤러는 구성의 외부 Webhook 목록을 사용하여 병렬로 호출합니다.

모든 웹 후크에서 요청을 승인하면 승인 체인이 계속됩니다.
웹 후크 중 하나 라도 요청을 거부하면 승인 요청이 거부되고 이를 수행하는 이유는 첫 번째 웹 후크 거부 이유를 기반으로 합니다.
둘 이상의 웹 후크가 승인 요청을 거부하면 첫 번째 웹 후크만 사용자에게 반환됩니다.
Webhook를 호출할 때 오류가 발생하면 해당 요청이 거부되거나 웹 후크가 무시됩니다.

승인 컨트롤러와 웹 후크 서버 간의 통신은 TLS를 사용하여 보안을 설정해야 합니다. CA 인증서를 생성하고 인증서를 사용하여 웹 후크 서버에서 사용하는 서버 인증서에 서명합니다. PEM 형식의 CA 인증서는 Service Serving 인증서 비밀 과 같은 메커니즘을 사용하여 승인 컨트롤러에 제공됩니다.

다음 다이어그램에서는 여러 웹 후크를 호출하는 두 개의 승인 Webhook가 있는 이 프로세스를 보여줍니다.

승인 Webhook의 간단한 사용 사례는 리소스의 구문 검증입니다. 예를 들어 모든 Pod에 공통 레이블 세트가 있어야 하는 인프라가 있으며, Pod에 해당 라벨이 없는 경우 Pod가 유지되지 않도록 합니다. 이러한 라벨과 다른 웹 후크를 삽입하도록 웹 후크를 작성하여 레이블이 있는지 확인할 수 있습니다. 그런 다음 OpenShift Container Platform은 라벨이 있는 Pod를 예약하고 유효성 검사를 통과하며 누락된 라벨으로 인해 전달되지 않는 Pod를 거부합니다.

일반적인 사용 사례는 다음과 같습니다.

사이드카 컨테이너를 포드에 삽입하기 위한 리소스 변경.
프로젝트에서 일부 리소스를 차단하도록 프로젝트를 제한합니다.
종속 필드에 복잡한 검증을 수행하는 사용자 정의 리소스 검증.

4.7.2.1. Admission Webhook의 유형

클러스터 관리자는 API 서버의 승인 체인에 승인 Webhook 또는 검증 승인 Webhook를 포함할 수 있습니다.

승인 프로세스 변경 단계에서 승인 Webhook 변경이 호출되므로 리소스 콘텐츠가 지속되기 전에 수정할 수 있습니다. 변경 승인 Webhook의 한 예로는 네임스페이스의 주석을 사용하여 라벨 선택기를 찾아 Pod 사양에 추가하는 Pod 노드 선택기 기능이 있습니다.

샘플 상호 승인 Webhook 구성

apiVersion: admissionregistration.k8s.io/v1beta1
  kind: MutatingWebhookConfiguration 1
  metadata:
    name: <controller_name> 2
  webhooks:
  - name: <webhook_name> 3
    clientConfig: 4
      service:
        namespace:  5
        name: 6
       path: <webhook_url> 7
      caBundle: <cert> 8
    rules: 9
    - operations: 10
      - <operation>
      apiGroups:
      - ""
      apiVersions:
      - "*"
      resources:
      - <resource>
    failurePolicy: <policy> 11

1

변경 승인 Webhook 구성을 지정합니다.

2

승인 Webhook 오브젝트의 이름입니다.

3

호출할 웹 후크의 이름입니다.

4

웹 후크 서버에 연결하고 신뢰하고 데이터를 전송하는 방법에 대한 정보입니다.

5

프론트엔드 서비스가 생성되는 프로젝트입니다.

6

프론트 엔드 서비스의 이름입니다.

7

승인 요청에 사용되는 웹 후크 URL입니다.

8

웹 후크 서버에서 사용하는 서버 인증서에 서명하는 PEM 인코딩 CA 인증서입니다.

9

API 서버가 이 컨트롤러를 사용해야 하는 시기를 정의하는 규칙입니다.

10

API 서버를 트리거하여 이 컨트롤러를 호출하는 작업은 다음과 같습니다.

create
update
delete
연결

11

웹 후크 승인 서버를 사용할 수 없는 경우 정책 진행 방법을 지정합니다. 무시 (허용/실패) 또는 실패 (블록/실패 마감).

승인 프로세스의 검증 단계 중에 승인 Webhook 검증이 호출됩니다. 이 단계에서는 특정 API 리소스에 대한 변형을 적용하여 리소스가 다시 변경되지 않게 합니다. Pod 노드 선택기는 프로젝트의 노드 선택기 제한으로 인해 모든 nodeSelector 필드가 제한되도록 하여 검증 승인의 예이기도 합니다.

Admission Webhook 구성 검증 샘플

apiVersion: admissionregistration.k8s.io/v1beta1
  kind: ValidatingWebhookConfiguration 1
  metadata:
    name: <controller_name> 2
  webhooks:
  - name: <webhook_name> 3
    clientConfig: 4
      service:
        namespace: default  5
        name: kubernetes 6
       path: <webhook_url> 7
      caBundle: <cert> 8
    rules: 9
    - operations: 10
      - <operation>
      apiGroups:
      - ""
      apiVersions:
      - "*"
      resources:
      - <resource>
    failurePolicy: <policy> 11