Risolvere i problemi relativi ai webhook di 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 assistenza, contatta l'assistenza clienti Google Cloud.

Tipi di webhook problematici

I webhook di ammissione, o webhook in Kubernetes, sono un tipo titolare di ammissione che possono essere utilizzate nei cluster Kubernetes per convalidare o modificare le richieste di controllo prima della persistenza di una richiesta. È normale 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 sul piano di controllo le prestazioni e l'affidabilità. 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 peggiorare la 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 supporta il webhook ha uno o più pod non in esecuzione. Per rendere disponibili gli endpoint webhook, segui le istruzioni per trovare e risolvere i problemi dei pod del servizio che supportano 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, significa che causata da una mancata corrispondenza tra il nome elencato configurazione e il nome effettivo del servizio. Per correggere la disponibilità dell'endpoint, aggiorna il nome del servizio nella configurazione dell'webhook in modo che corrisponda all'oggetto Service corretto.

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

    kubectl get deployment -n SERVICE_NAMESPACE

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

    kubectl get pods -n SERVICE_NAMESPACE -o wide

    Per tutti i pod che non sono 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 gli webhook per evitare di intercettare queste risorse.

  1. Controlla la configurazione dell'webhook. Esegui il seguente comando kubectl per recuperare la configurazione dell'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 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 opera 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 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 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 Assistenza clienti Google Cloud.