Soluciona problemas de webhooks de Google Distributed Cloud

En esta página, se muestra cómo resolver problemas relacionados con webhooks problemáticos o inseguros en Google Distributed Cloud.

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.

Tipos de webhooks problemáticos

Los webhooks de admisión, o webhooks en Kubernetes, son un tipo de controlador de admisión que se puede usar en los clústeres de Kubernetes para validar o mutar las solicitudes al plano de control antes de que persista una solicitud. Es común que las aplicaciones de terceros usen webhooks que operan en recursos críticos del sistema y espacios de nombres. Los webhooks configurados de forma incorrecta pueden afectar el rendimiento y la confiabilidad del plano de control. Por ejemplo, un webhook configurado de forma incorrecta y creado por una aplicación de terceros podría impedir que Google Distributed Cloud cree y modifique recursos en el espacio de nombres kube-system administrado, lo que podría degradar la funcionalidad del clúster.

Los webhooks con problemas incluyen los siguientes tipos:

Webhooks que no tienen extremos disponibles

Si un webhook no tiene extremos disponibles, el Service que respalda el extremo de webhook tiene uno o más Pods que no se están ejecutando. Si deseas que los extremos de webhook estén disponibles, sigue las instrucciones para encontrar los Pods del Service que respaldan este extremo de webhook y solucionar los problemas relacionados con él:

  1. Busca los Pods de entrega para el Service asociado con el webhook. Ejecuta el siguiente comando para describir el servicio:

    kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE

    Reemplaza lo siguiente:

    • SERVICE_NAME por el nombre del Service
    • SERVICE_NAMESPACE por el nombre del espacio de nombres

    Si no puedes encontrar el nombre del servicio enumerado en el webhook, el extremo no disponible podría deberse a una discrepancia entre el nombre que aparece en la configuración y el nombre real del servicio. Para corregir la disponibilidad del extremo, actualiza el nombre del Service en la configuración del webhook para que coincida con el objeto Service correcto.

  2. Inspecciona los Pods de entrega para este Service. Para identificar qué Pods no se están ejecutando, enumera la Deployment:

    kubectl get deployment -n SERVICE_NAMESPACE

    También puedes ejecutar el comando siguiente para mostrar los Pods:

    kubectl get pods -n SERVICE_NAMESPACE -o wide

    Si hay Pods que no estén en ejecución, inspecciona los registros del Pod para ver por qué no se está ejecutando.

Webhooks que se consideran poco seguros

Si un webhook intercepta algún recurso en los espacios de nombres administrados por el sistema, te recomendamos que actualices los webhooks para evitar interceptar estos recursos.

  1. Inspeccionar la configuración del webhook Ejecuta el siguiente comando de kubectl para obtener la configuración del webhook:

    kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml

    Reemplaza CONFIGURATION_NAME por el nombre de la configuración de webhooks.

    Si este comando no muestra nada, vuelve a ejecutarlo y reemplaza validatingwebhookconfigurations por mutatingwebhookconfigurations.

    En la sección webhooks del resultado, se enumeran uno o más webhooks.

  2. Edita la configuración, según el motivo por el que el webhook se considera poco seguro:

    Excluye los espacios de nombres kube-system y kube-node-lease

    Un webhook se considera no seguro si scope es * o si el alcance es Namespaced y se cumple alguna de las siguientes condiciones:

    • La condición operator es NotIn, y values omite kube-system y kube-node-lease, como se muestra en el siguiente ejemplo:

      webhooks:
- admissionReviewVersions:
  ...
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - blue-system # add 'kube-system' and 'kube-node-lease' if `NotIn`
  objectSelector: {}
  rules:
  - apiGroups:
    ...
    scope: '*' # 'Namespaced'
  sideEffects: None
  timeoutSeconds: 3

      Asegúrate de que scope esté configurado como Namespaced, no *, para que el webhook solo funcione en espacios de nombres específicos. Asegúrate de que si operator es NotIn, kube-system y kube-node-lease se incluyan en values.

    • La condición operator es In, y values incluye kube-system y kube-node-lease, como se muestra en el siguiente ejemplo:

      namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: In
      values:
      - blue-system
      - kube-system # remove as operator is `In`
      - kube-node-lease # remove as operator is `In`

      Asegúrate de que scope esté configurado como Namespaced, no *, para que el webhook solo funcione en espacios de nombres específicos. Asegúrate de que si operator es In, kube-system y kube-node-lease no se incluyan en values.

    Excluye recursos coincidentes

    Un webhook también se considera no seguro si nodes, tokenreviews, subjectaccessreviews o certificatesigningrequests se enumeran en recursos, como en el siguiente ejemplo:

    - admissionReviewVersions:
...
    resources:
    - 'pods' # keep, remove everything else
    - 'nodes'
    - 'tokenreviews'
    - 'subjectacessreviews'
    - 'certificatesigningrequests'
    scope: '*'
  sideEffects: None
  timeoutSeconds: 3

    Quita nodes, tokenreviews, subjectaccessreviews y certificatesigningrequests de la sección de recursos.

¿Qué sigue?

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.