Soluciona problemas de webhook de Google Distributed Cloud

En esta página, se muestra cómo resolver problemas con webhooks problemáticos o no seguros 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 decontrolador de admisión que se puede usar en clústeres de Kubernetes para validar o mutar solicitudes al plano de control antes de que se conserve 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 mediante una aplicación de terceros podría evitar 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 problemáticos incluyen los siguientes tipos:

Webhooks que no tienen extremos disponibles

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

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

    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 Service en el webhook, el extremo no disponible puede deberse a una discrepancia entre el nombre que aparece en la configuración y el nombre real del Service. 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 los Pods que no se están ejecutando, enumera la implementación:

    kubectl get deployment -n SERVICE_NAMESPACE

    O bien, ejecuta el siguiente comando para enumerar los Pods:

    kubectl get pods -n SERVICE_NAMESPACE -o wide

    En el caso de los Pods que no se están ejecutando, inspecciona los registros de Pod para ver por qué no se están ejecutando.

Webhooks que se consideran poco seguros

Si un webhook intercepta cualquier recurso en los espacios de nombres administrados por el sistema, te recomendamos que actualices los webhooks para evitar la interceptación de estos recursos.

  1. Inspecciona 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 webhook.

    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 permiso es Namespaced y si alguna de las siguientes condiciones es verdadera:

    • 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 poco seguro si nodes, tokenreviews, subjectaccessreviews o certificatesigningrequests aparecen en los 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.