Какие есть два вида admission-вебхуков?

Два вида admission-вебхуков в Kubernetes

В Kubernetes существуют два основных вида admission-вебхуков (admission webhooks): Validating Admission Webhooks и Mutating Admission Webhooks. Они являются ключевыми компонентами Dynamic Admission Control и позволяют настраивать и расширять политики управления кластером. Их основная роль — перехватывать запросы к API-серверу Kubernetes до сохранения объекта в etcd, что обеспечивает дополнительный уровень контроля и безопасности.

1. Validating Admission Webhooks (Валидирующие вебхуки)

Validating Admission Webhooks предназначены для валидации (проверки) запросов. Они не могут изменять объекты, а лишь проверяют их на соответствие определённым правилам и политикам. Если валидация не проходит, запрос отклоняется.

• Цель: Обеспечение соблюдения политик безопасности, соответствия стандартам и бизнес-правилам.
• Момент срабатывания: После этапа мутации (если есть Mutating Webhooks), непосредственно перед сохранением объекта.
• Действие: Только проверка. Возвращает разрешение (allow: true) или запрет (allow: false) с пояснением ошибки.
• Примеры использования:

    *   Проверка, что все Pod'ы имеют указанные метки (`team`, `env`).
    *   Валидация, что в Pod'е не используются привилегированные контейнеры (`privileged: false`).
    *   Проверка корректности формата имен ресурсов.
    *   Обеспечение того, что все исходящие сетевые политики (`NetworkPolicy`) определены.

Пример минимального манифеста ValidatingWebhookConfiguration:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: "pod-policy.example.com"
webhooks:
  - name: "pod-policy.example.com"
    clientConfig:
      service:
        name: "webhook-service"
        namespace: "default"
        path: "/validate"
        port: 443
      caBundle: "<CA_CERTIFICATE>"
    rules:
      - operations: ["CREATE", "UPDATE"]
        apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]
    admissionReviewVersions: ["v1"]
    sideEffects: None
    timeoutSeconds: 5
    failurePolicy: Fail

2. Mutating Admission Webhooks (Мутирующие вебхуки)

Mutating Admission Webhooks предназначены для модификации (изменения) объектов. Они могут добавлять, удалять или изменять поля в запросе перед его валидацией и сохранением.

• Цель: Автоматическое добавление стандартных полей, внедрение sidecar-контейнеров, установка значений по умолчанию.
• Момент срабатывания: До этапа валидации. Изменённый объект затем передаётся на валидацию (в том числе и в Validating Webhooks).
• Действие: Модификация объекта. Возвращает изменённую версию объекта в поле patch ответа (обычно в формате JSON Patch).
• Примеры использования:

    *   Автоматическое добавление меток или аннотаций ко всем создаваемым ресурсам.
    *   Внедрение sidecar-контейнера (например, для прокси или логирования) во все Pod'ы определённого namespace.
    *   Добавление `resource limits` по умолчанию к контейнерам, где они не указаны.
    *   Модификация `image` контейнера для использования корпоративного реестра.

Пример минимального манифеста MutatingWebhookConfiguration:

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: "inject-sidecar.example.com"
webhooks:
  - name: "inject-sidecar.example.com"
    clientConfig:
      service:
        name: "webhook-service"
        namespace: "default"
        path: "/mutate"
        port: 443
      caBundle: "<CA_CERTIFICATE>"
    rules:
      - operations: ["CREATE"]
        apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]
    admissionReviewVersions: ["v1"]
    sideEffects: NoneOnDryRun
    timeoutSeconds: 5
    failurePolicy: Fail

Ключевые различия и особенности

Важные аспекты для DevOps. Опыт из практики:

1. Порядок имеет значение: Kubernetes может вызывать несколько вебхуков одного типа. Их порядок не гарантирован, если не использовать аннотацию webhook-ordering. Это важно для сложных сценариев, где одна мутация зависит от другой.

2. failurePolicy — критическая настройка: Определяет поведение API-сервера при недоступности вебхука.

    *   `Fail`: Запрос блокируется. Используется для **строгих проверок безопасности**.
    *   `Ignore`: Запрос проходит дальше. Может использоваться для **некритичных мутаций**, но требует осторожности.

1. sideEffects и безопасность: Параметр указывает, имеет ли вебхук побочные эффекты (например, создание внешних ресурсов). Для вебхуков, которые только читают данные, можно установить sideEffects: None или NoneOnDryRun, что позволяет их вызывать для dry-run запросов (kubectl --dry-run=server).

2. TLS и аутентификация: Вебхуки требуют HTTPS. Необходимо настроить TLS-сертификаты (часто через cert-manager) и указать корневой сертификат (caBundle) в конфигурации. В production-средах вебхук.

3. Отказоустойчивость и производительность: Вебхуки — это точка отказа. Они должны быть быстрыми (timeoutSeconds часто ставят 5-10 сек) и развёрнутыми с высокой доступностью. Длительные вызовы блокируют API.

    *   Рекомендуется мониторить метрики latency и error rate эндпоинтов вебхуков.

Вывод: Грамотное сочетание Mutating и Validating Webhooks позволяет построить мощную, самоуправляемую и безопасную платформу в Kubernetes. Mutating автоматизирует и стандартизирует, а Validating — обеспечивает соблюдение неизменяемых правил, выступая последним рубежом защиты. Их реализация требует внимания к безопасности связи, производительности и логике порядка выполнения.