Risoluzione dei problemi relativi al webhook Google Distributed Cloud

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

Se hai bisogno di ulteriore aiuto, contatta l'assistenza clienti Google 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 piano di controllo prima che una richiesta sia persistente. È comune per le applicazioni di terze parti utilizzare webhook che operano su risorse e spazi dei nomi critici per il sistema. I webhook configurati in modo errato possono influire sulle prestazioni e sull'affidabilità del piano di controllo. 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 risorse nello spazio dei nomi kube-system gestito, con conseguente peggioramento della funzionalità del cluster.

I webhook problematici includono i seguenti tipi:

Webhook che non hanno endpoint disponibili

Se un webhook non ha endpoint disponibili, il servizio che esegue il backup dell'endpoint webhook ha uno o più pod che non sono in esecuzione. Per rendere disponibili gli endpoint webhook, segui le istruzioni per trovare e risolvere i problemi dei pod del servizio su cui si basa questo endpoint webhook:

  1. Trova i pod di gestione per il servizio associato al webhook. Esegui questo comando 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 correggere la disponibilità dell'endpoint, aggiorna il nome del servizio nella configurazione del webhook in modo che corrisponda all'oggetto di servizio corretto.

  2. Esaminare i pod di gestione per questo servizio. Identifica quali pod non sono in esecuzione elencando il deployment:

    kubectl get deployment -n SERVICE_NAMESPACE
    

    In alternativa, esegui questo comando per elencare i pod:

    kubectl get pods -n SERVICE_NAMESPACE -o wide
    

    Nel caso di pod non in esecuzione, controlla i log dei pod per capire perché non è 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. Esamina la configurazione del webhook. Esegui questo 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 il comando non restituisce nulla, eseguilo di nuovo, 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 una delle seguenti condizioni è vera:

    • 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 sono 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 risorse corrispondenti

    Un webhook è considerato non sicuro anche se nella sezione Risorse sono elencati nodes, tokenreviews, subjectaccessreviews o certificatesigningrequests, 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 aiuto, contatta l'assistenza clienti Google Cloud.