Risolvere i problemi relativi ai webhook di Google Distributed Cloud

Questa pagina mostra 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 possono essere utilizzati nei cluster Kubernetes per convalidare o modificare le richieste al control plane prima che una richiesta venga resa persistente. È comune che le applicazioni di terze parti utilizzino 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 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 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 relativi ai pod del servizio che supporta questo endpoint webhook:

  1. Trova i pod di pubblicazione 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 risolvere il problema di disponibilità dell'endpoint, aggiorna il nome del servizio nella configurazione del webhook in modo che corrisponda all'oggetto Service 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 questo comando per elencare i pod:

    kubectl get pods -n SERVICE_NAMESPACE -o wide

    Per i pod che non sono in esecuzione, controlla i log per capire perché il pod non è in esecuzione.

Webhook considerati non sicuri

Se un webhook intercetta risorse in 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 questo 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 si verifica una delle seguenti condizioni:

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

      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 operi 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 nel seguente esempio:

      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 operi 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 nodes, tokenreviews, subjectaccessreviews o certificatesigningrequests sono elencati in risorse, come nel seguente esempio:

    - 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 sezione Richiedere assistenza per ulteriori informazioni sulle risorse di assistenza, tra cui: