Resolva problemas de webhook do Google Distributed Cloud

Esta página mostra como resolver problemas com webhooks problemáticos ou inseguros no Google Distributed Cloud.

Tipos de webhooks problemáticos

Os webhooks de admissão, ou webhooks no Kubernetes, são um tipo de controlador de admissão que podem ser usados em clusters do Kubernetes para validar ou alterar pedidos ao plano de controlo antes de um pedido ser persistido. É comum as aplicações de terceiros usarem webhooks que operam em recursos e espaços de nomes críticos para o sistema. Os webhooks configurados incorretamente podem afetar o desempenho e a fiabilidade do plano de controlo. Por exemplo, um webhook configurado incorretamente criado por uma aplicação de terceiros pode impedir que o Google Distributed Cloud crie e modifique recursos no espaço de nomes kube-system gerido, o que pode degradar a funcionalidade do cluster.

Os webhooks problemáticos incluem os seguintes tipos:

Webhooks que não têm pontos finais disponíveis

Se um webhook não tiver pontos finais disponíveis, o serviço que suporta o ponto final do webhook tem um ou mais pods que não estão em execução. Para disponibilizar os pontos finais do webhook, siga as instruções para encontrar e resolver problemas dos pods do serviço que suporta este ponto final do webhook:

  1. Encontre os pods de publicação para o serviço associado ao webhook. Execute o seguinte comando para descrever o serviço:

    kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE

    Substitua o seguinte:

    • SERVICE_NAME com o nome do Serviço.
    • SERVICE_NAMESPACE com o nome do espaço de nomes.

    Se não conseguir encontrar o nome do serviço indicado no webhook, o ponto final indisponível pode ser causado por uma falta de correspondência entre o nome indicado na configuração e o nome real do serviço. Para corrigir a disponibilidade do ponto final, atualize o nome do serviço na configuração do webhook para corresponder ao objeto de serviço correto.

  2. Inspeccione os pods de publicação deste serviço. Identifique os pods que não estão a ser executados listando a implementação:

    kubectl get deployment -n SERVICE_NAMESPACE

    Em alternativa, execute o seguinte comando para apresentar uma lista dos pods:

    kubectl get pods -n SERVICE_NAMESPACE -o wide

    Para todos os pods que não estejam em execução, inspecione os registos dos pods para ver por que motivo o pod não está em execução.

Webhooks considerados inseguros

Se um webhook intercetar recursos em espaços de nomes geridos pelo sistema, recomendamos que atualize os webhooks para evitar a interceção destes recursos.

  1. Inspeccione a configuração do webhook. Execute o seguinte comando kubectl para obter a configuração do webhook:

    kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml

    Substitua CONFIGURATION_NAME pelo nome da configuração do webhook.

    Se este comando não devolver nada, execute-o novamente, substituindo validatingwebhookconfigurations por mutatingwebhookconfigurations.

    Na secção webhooks do resultado, são apresentados um ou mais webhooks.

  2. Edite a configuração, consoante o motivo pelo qual o webhook é considerado não seguro:

    Exclua os espaços de nomes kube-system e kube-node-lease

    Um webhook é considerado não seguro se scope for * ou se o âmbito for Namespaced e qualquer uma das seguintes condições for verdadeira:

    • A condição operator é NotIn e values omite kube-system e kube-node-lease, como no exemplo seguinte:

      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

      Certifique-se de que scope está definido como Namespaced e não como *, para que o webhook funcione apenas em espaços de nomes específicos. Certifique-se de que, se operator for NotIn, kube-system e kube-node-lease estão incluídos em values.

    • A condição operator é In e values inclui kube-system e kube-node-lease, como no exemplo seguinte:

      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`

      Certifique-se de que scope está definido como Namespaced e não como *, para que o webhook funcione apenas em espaços de nomes específicos. Certifique-se de que, se operator for In, kube-system e kube-node-lease não estão incluídos em values.

    Exclua recursos correspondentes

    Um webhook também é considerado não seguro se nodes, tokenreviews, subjectaccessreviews ou certificatesigningrequests estiverem listados em resources, como no exemplo seguinte:

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

    Remova nodes, tokenreviews, subjectaccessreviews e certificatesigningrequests da secção de recursos.

O que se segue?

Se precisar de assistência adicional, contacte o apoio ao cliente do Google Cloud. Também pode consultar o artigo Receber apoio técnico para mais informações sobre recursos de apoio técnico, incluindo o seguinte:

  • Requisitos para abrir um registo de apoio técnico.
  • Ferramentas para ajudar a resolver problemas, como a configuração do ambiente, os registos e as métricas.
  • Componentes suportados.