Résoudre les problèmes liés aux webhooks GKE sur VMware

Cette page explique comment résoudre les problèmes de webhooks problématiques ou non sécurisés dans GKE sur VMware.

Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.

Types de webhooks problématiques

Les webhooks d'admission, ou webhooks dans Kubernetes, sont un type de contrôleur d'admission pouvant être utilisé dans les clusters Kubernetes pour valider ou modifier les requêtes adressées au plan de contrôle avant qu'une requête ne soit conservée. Il est courant que les applications tierces utilisent des webhooks qui fonctionnent sur des ressources et des espaces de noms critiques du système. Des webhooks mal configurés peuvent affecter les performances et la fiabilité du plan de contrôle. Par exemple, un webhook mal configuré créé par une application tierce peut empêcher GKE sur VMware de créer et de modifier des ressources dans l'espace de noms kube-system géré, ce qui peut dégrader les fonctionnalités du cluster.

Voici les types de webhooks problématiques:

Webhooks sans point de terminaison disponible

Si un webhook ne dispose d'aucun point de terminaison disponible, le service qui le soutient comporte un ou plusieurs pods qui ne sont pas en cours d'exécution. Pour rendre les points de terminaison de webhook disponibles, suivez les instructions afin de rechercher et de dépanner les pods du service qui sauvegarde ce point de terminaison de webhook:

  1. Recherchez les pods de diffusion du service associé au webhook. Exécutez la commande suivante pour décrire le service:

    kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE

    Remplacez les éléments suivants :

    • SERVICE_NAME par le nom du service ;
    • SERVICE_NAMESPACE par le nom de l'espace de noms.

    Si vous ne trouvez pas le nom du service indiqué dans le webhook, l'indisponibilité du point de terminaison peut être due à une non-concordance entre le nom indiqué dans la configuration et le nom réel du service. Pour corriger la disponibilité du point de terminaison, mettez à jour le nom du service dans la configuration du webhook afin qu'il corresponde à l'objet de service approprié.

  2. Inspecter les pods actifs pour ce service. Identifiez les pods qui ne s'exécutent pas en répertoriant le déploiement:

    kubectl get deployment -n SERVICE_NAMESPACE

    Vous pouvez également exécuter la commande suivante pour obtenir la liste des pods:

    kubectl get pods -n SERVICE_NAMESPACE -o wide

    Pour tous les pods qui ne sont pas en cours d'exécution, inspectez les journaux des pods pour en déterminer la raison.

Webhooks considérés comme non sécurisés

Si un webhook intercepte des ressources dans des espaces de noms gérés par le système, nous vous recommandons de mettre à jour les webhooks pour éviter d'intercepter ces ressources.

  1. Inspectez la configuration du webhook. Exécutez la commande kubectl suivante pour obtenir la configuration du webhook:

    kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml

    Remplacez CONFIGURATION_NAME par le nom de la configuration du webhook.

    Si cette commande ne renvoie rien, exécutez-la à nouveau en remplaçant validatingwebhookconfigurations par mutatingwebhookconfigurations.

    Dans la section webhooks du résultat, un ou plusieurs webhooks sont répertoriés.

  2. Modifiez la configuration en fonction de la raison pour laquelle le webhook est considéré comme non sécurisé:

    Exclure les espaces de noms kube-system et kube-node-lease

    Un webhook est considéré comme non sécurisé si scope est défini sur *, ou si le champ d'application est Namespaced et que l'une des conditions suivantes est remplie:

    • La condition operator est NotIn, et values omet kube-system et kube-node-lease, comme dans l'exemple suivant :

      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

      Assurez-vous que scope est défini sur Namespaced, et non sur *, afin que le webhook ne fonctionne que dans des espaces de noms spécifiques. Assurez-vous que si operator est défini sur NotIn, kube-system et kube-node-lease sont inclus dans values.

    • La condition operator est définie sur In, et values inclut kube-system et kube-node-lease, comme dans l'exemple suivant :

      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`

      Assurez-vous que scope est défini sur Namespaced, et non sur *, afin que le webhook ne fonctionne que dans des espaces de noms spécifiques. Assurez-vous que si operator est défini sur In, kube-system et kube-node-lease ne sont pas inclus dans values.

    Exclure les ressources correspondantes

    Un webhook est également considéré comme non sécurisé si nodes, tokenreviews, subjectaccessreviews ou certificatesigningrequests sont répertoriés sous les ressources, comme dans l'exemple suivant:

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

    Supprimez nodes, tokenreviews, subjectaccessreviews et certificatesigningrequests de la section des ressources.

Étapes suivantes

Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care.