Resolver problemas de webhook do Google Distributed Cloud

Nesta página, mostramos como resolver problemas com webhooks problemáticos ou não seguros no Google Distributed Cloud.

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.

Tipos de webhooks problemáticos

Webhooks de admissão, ou webhooks no Kubernetes, são um tipo de controlador de admissão que pode ser usado em clusters do Kubernetes para validar ou modificar solicitações para o plano de controle antes que elas sejam mantidas. É comum que aplicativos de terceiros usem webhooks que operam em recursos e namespaces críticos para o sistema. Os webhooks configurados incorretamente podem afetar o desempenho e a confiabilidade do plano de controle. Por exemplo, um webhook configurado incorretamente criado por um aplicativo de terceiros pode impedir que o Google Distributed Cloud crie e modifique recursos no namespace kube-system gerenciado, o que pode prejudicar a funcionalidade do cluster.

Os webhooks problemáticos incluem os seguintes tipos:

• Webhooks que funcionam, mas não têm endpoints disponíveis. Siga as instruções para verificar os webhooks sem endpoints disponíveis.

• Webhooks considerados não seguros quando operam em recursos e namespaces críticos do sistema.

  Os webhooks abaixo são considerados não seguros:

  • Webhooks que interceptam pods e leases no namespace kube-system.
  • Webhooks que interceptam leases no namespace kube-node-lease.
  • Webhooks que interceptam os recursos Nodes, TokenReviews, SubjectAccessReviews e CertificateSigningRequests .

  Siga as instruções para verificar os webhooks que são considerados não seguros.

Webhooks que não têm endpoints disponíveis

Se um webhook não tiver endpoints disponíveis, o serviço que apoia o endpoint do webhook terá um ou mais pods que não estarão em execução. Para disponibilizar os endpoints do webhook, siga as instruções para encontrar e resolver problemas de pods do serviço que dá suporte a eles:

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

   kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE
   

   Substitua:

   • SERVICE_NAME pelo nome do serviço.
   • SERVICE_NAMESPACE pelo nome do namespace.

   Se você não encontrar o nome do serviço listado no webhook, o endpoint indisponível poderá ser causado por uma incompatibilidade entre o nome listado na configuração e o nome real do serviço. Para corrigir a disponibilidade do endpoint, atualize o nome do serviço na configuração do webhook para corresponder ao objeto de serviço correto.

2. Inspecione os pods de exibição em busca desse serviço. Identifique quais pods não estão em execução listando a implantação:

   kubectl get deployment -n SERVICE_NAMESPACE
   

   Também é possível executar o seguinte comando para listar os pods:

   kubectl get pods -n SERVICE_NAMESPACE -o wide
   

   Inspecione os registros de pods que não estejam em execução para saber por que eles não estão em execução.

Webhooks considerados não seguros

Se um webhook interceptar recursos em namespaces gerenciados pelo sistema, a recomendação será a atualização para evitar a interceptação desses recursos.

1. Inspecione a configuração do webhook. Execute o seguinte comando kubectl para conferir a configuração do webhook:

   kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml
   

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

   Se esse comando não retornar nada, execute o comando novamente, substituindo validatingwebhookconfigurations por mutatingwebhookconfigurations.

   Na seção webhooks da saída, um ou mais webhooks são listados.

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

   Excluir namespaces kube-system e kube-node-lease

   Um webhook não será considerado seguro se scope for * ou se o escopo for Namespaced e uma das seguintes condições for verdadeira:

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

     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
     

     Verifique se scope está definido como Namespaced, não *, para que o webhook opere apenas em namespaces específicos. Verifique se operator é 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 a seguir:

     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`
     

     Verifique se scope está definido como Namespaced, não *, para que o webhook opere apenas em namespaces específicos. Verifique se operator é In, kube-system e kube-node-lease não estão incluídos em values.

   Excluir recursos correspondentes

   Um webhook também é considerado não seguro quando nodes, tokenreviews, subjectaccessreviews ou certificatesigningrequests estão listados em recursos, como no seguinte exemplo:

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

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

A seguir

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.