Risolvere i problemi relativi ai webhook di Google Distributed Cloud

Questa pagina spiega come risolvere i problemi relativi ai webhook problematici o non sicuri in Google Distributed Cloud.

Tipi di webhook problematici

I webhook di ammissione, o webhook in Kubernetes, sono un tipo di controller di ammissione che può essere utilizzato nei cluster Kubernetes per convalidare o modificare le richieste al control plane prima che vengano rese persistenti. È comune che le applicazioni di terze parti utilizzino webhook che operano su risorse e spazi dei nomi di importanza critica per il sistema. I webhook configurati in modo errato possono influire sulle prestazioni e sull'affidabilità del control plane. Ad esempio, un webhook configurato in modo errato creato da un'applicazione di terze parti potrebbe impedire a Google Distributed Cloud di creare e modificare le risorse nello spazio dei nomi kube-system gestito, il che potrebbe compromettere la funzionalità del cluster.

I webhook problematici includono i seguenti tipi:

Webhook senza endpoint disponibili

Se un webhook non ha endpoint disponibili, il servizio che supporta l'endpoint del webhook ha uno o più pod che non sono in esecuzione. Per rendere disponibili gli endpoint del webhook, segui le istruzioni per trovare e risolvere i problemi relativi ai pod del servizio che supporta questo endpoint del webhook:

  1. Trova i pod di pubblicazione per il servizio associato al webhook. Esegui il comando seguente per descrivere il servizio:

    kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE

    Sostituisci quanto segue:

    • SERVICE_NAME con il nome del servizio.
    • SERVICE_NAMESPACE con il nome dello spazio dei nomi.

    Se non riesci a trovare il nome del servizio elencato nel webhook, l'endpoint non disponibile potrebbe essere causato da una mancata corrispondenza tra il nome elencato nella configurazione e il nome effettivo del servizio. Per risolvere il problema di disponibilità dell'endpoint, aggiorna il nome del servizio nella configurazione del webhook in modo che corrisponda all'oggetto del servizio corretto.

  2. Ispeziona i pod di pubblicazione per questo servizio. Identifica i pod che non sono in esecuzione elencando il deployment:

    kubectl get deployment -n SERVICE_NAMESPACE

    In alternativa, esegui il comando seguente per elencare i pod:

    kubectl get pods -n SERVICE_NAMESPACE -o wide

    Per i pod che non sono in esecuzione, controlla i log dei pod per scoprire perché non sono in esecuzione.

Webhook considerati non sicuri

Se un webhook intercetta risorse negli spazi dei nomi gestiti dal sistema, ti consigliamo di aggiornare i webhook per evitare di intercettare queste risorse.

  1. Ispeziona la configurazione del webhook. Esegui il seguente comando kubectl per ottenere la configurazione del webhook:

    kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml

    Sostituisci CONFIGURATION_NAME con il nome della configurazione del webhook.

    Se questo comando non restituisce nulla, esegui di nuovo il comando, sostituendo validatingwebhookconfigurations con mutatingwebhookconfigurations.

    Nella sezione webhooks dell'output sono elencati uno o più webhook.

  2. Modifica la configurazione, a seconda del motivo per cui il webhook è considerato non sicuro:

    Escludi gli spazi dei nomi kube-system e kube-node-lease

    Un webhook è considerato non sicuro se scope è * o se l'ambito è Namespaced e si verifica una delle seguenti condizioni:

    • La condizione operator è NotIn e values omette kube-system e kube-node-lease, come nell'esempio seguente:

      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

      Assicurati che scope sia impostato su Namespaced, non su *, in modo che il webhook funzioni solo in spazi dei nomi specifici. Assicurati che, se operator è NotIn, kube-system e kube-node-lease siano inclusi in values.

    • La condizione operator è In e values include kube-system e kube-node-lease, come nell'esempio seguente:

      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`

      Assicurati che scope sia impostato su Namespaced, non su *, in modo che il webhook funzioni solo in spazi dei nomi specifici. Assicurati che, se operator è In, kube-system e kube-node-lease non siano inclusi in values.

    Escludi le risorse corrispondenti

    Un webhook è considerato non sicuro anche se nodes, tokenreviews, subjectaccessreviews o certificatesigningrequests sono elencati in risorse, come nell'esempio seguente:

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

    Rimuovi nodes, tokenreviews, subjectaccessreviews e certificatesigningrequests dalla sezione delle risorse.

Passaggi successivi

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.

Puoi anche consultare la pagina Richiedere assistenza per ulteriori informazioni sulle risorse di assistenza, tra cui:

  • Requisiti per l'apertura di una richiesta di assistenza.
  • Strumenti per la risoluzione dei problemi, come log e metriche.
  • Componenti , , and supportati, versioni e funzionalità di Google Distributed Cloud per VMware (solo software).