Résoudre les problèmes liés aux charges de travail et aux listes d'autorisation Autopilot privilégiées

Les charges de travail privilégiées dans les clusters Google Kubernetes Engine (GKE) Autopilot doivent être configurées correctement pour éviter tout problème. Les erreurs de configuration peuvent entraîner des échecs de synchronisation avec les listes d'autorisation ou le rejet de la charge de travail. Ces problèmes peuvent empêcher les agents ou services essentiels de s'exécuter avec les autorisations nécessaires.

Utilisez ce document pour résoudre les problèmes liés au déploiement de charges de travail privilégiées sur Autopilot. Découvrez comment résoudre les erreurs de synchronisation de la liste d'autorisation et diagnostiquer les raisons pour lesquelles une charge de travail privilégiée peut être refusée.

Ces informations sont importantes pour les administrateurs et opérateurs de plate-forme, ainsi que pour les équipes de sécurité qui déploient des charges de travail avec des autorisations élevées sur les clusters Autopilot. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez Rôles utilisateur et tâches courantes de GKE.

Problèmes de synchronisation de la liste d'autorisation

Lorsque vous déployez un AllowlistSynchronizer, GKE tente d'installer et de synchroniser les fichiers de liste d'autorisation que vous spécifiez. Si cette synchronisation échoue, le champ status de AllowlistSynchronizer signale l'erreur.

Obtenez l'état de l'objet AllowlistSynchronizer :

kubectl get allowlistsynchronizer ALLOWLIST_SYNCHRONIZER_NAME -o yaml

Remplacez ALLOWLIST_SYNCHRONIZER_NAME par le nom de l'AllowlistSynchronizer.

Le résultat ressemble à ce qui suit :

...
status:
  conditions:
  - type: Ready
    status: "False"
    reason: "SyncError"
    message: "some allowlists failed to sync: example-allowlist-1.yaml"
    lastTransitionTime: "2024-10-12T10:00:00Z"
    observedGeneration: 2
  managedAllowlistStatus:
    - filePath: "gs://path/to/allowlist1.yaml"
      generation: 1
      phase: Installed
      lastSuccessfulSync: "2024-10-10T10:00:00Z"
    - filePath: "gs://path/to/allowlist2.yaml"
      phase: Failed
      lastError: "Initial install failed: invalid contents"
      lastSuccessfulSync: "2024-10-08T10:00:00Z"

Les champs conditions.message et managedAllowlistStatus.lastError fournissent des informations détaillées sur l'erreur. Utilisez ces informations pour résoudre le problème.

Plusieurs AllowlistSynchronizers

Dans les clusters GKE exécutant des versions antérieures à 1.33.4-gke.1035000, l'installation de WorkloadAllowlists peut échouer si plusieurs AllowlistSynchronizer sont présents.

Pour résoudre le problème, n'utilisez qu'un seul AllowlistSynchronizer contenant plusieurs allowlistPaths.

Vous pouvez également mettre à niveau votre cluster vers une version plus récente.

Tri des conteneurs de charge de travail

Dans les clusters GKE dont la version est antérieure à 1.34.0-gke.0000000, si une ou plusieurs images de conteneur de charge de travail correspondent à une image de conteneur spécifiée dans une liste d'autorisation de charge de travail dans le cluster, les conteneurs de charge de travail peuvent être créés et triés par ordre alphabétique inverse.

Pour résoudre ce problème, essayez les options suivantes :

  • Mettez à niveau votre cluster vers la version 1.34.0-gke.0000000 ou ultérieure.
  • Renommez les conteneurs de votre charge de travail pour qu'ils soient triés dans le bon ordre.

Problèmes de déploiement de charges de travail privilégiées

Une fois la liste d'autorisation installée, vous déployez la charge de travail privilégiée correspondante dans votre cluster. Dans certains cas, GKE peut refuser la charge de travail.

Essayez les options de résolution suivantes :

  • Assurez-vous que la version GKE de votre cluster répond aux exigences de version de la charge de travail.
  • Assurez-vous que la charge de travail que vous déployez est celle à laquelle s'applique le fichier de liste d'autorisation.

Pour savoir pourquoi une charge de travail privilégiée a été refusée, demandez des informations détaillées à GKE sur les cas de non-respect de la liste d'autorisation :

  1. Obtenez la liste des listes d'autorisation installées dans le cluster :

    kubectl get workloadallowlist

    Recherchez le nom de la liste d'autorisation qui doit s'appliquer à la charge de travail privilégiée.

  2. Ouvrez le fichier manifeste YAML de la charge de travail privilégiée dans un éditeur de texte. Si vous ne pouvez pas accéder aux fichiers manifestes YAML (par exemple, si le processus de déploiement de la charge de travail utilise d'autres outils), contactez le fournisseur de la charge de travail pour signaler un problème. Vous pouvez ignorer les autres étapes.

  3. Ajoutez le libellé suivant à la section spec.metadata.labels de la spécification de pod de la charge de travail privilégiée :

    labels:
  cloud.google.com/matching-allowlist: ALLOWLIST_NAME

    Remplacez ALLOWLIST_NAME par le nom de la liste d'autorisation que vous avez obtenue à l'étape précédente. Utilisez le nom de la sortie de la commande kubectl get workloadallowlist, et non le chemin d'accès au fichier de la liste d'autorisation.

  4. Enregistrez le fichier manifeste et appliquez la charge de travail au cluster :

    kubectl apply -f WORKLOAD_MANIFEST_FILE

    Remplacez WORKLOAD_MANIFEST_FILE par le chemin d'accès au fichier manifeste.

    Le résultat fournit des informations détaillées sur les champs de la charge de travail qui ne correspondent pas à la liste d'autorisation spécifiée, comme dans l'exemple suivant :

    Error from server (GKE Warden constraints violations): error when creating "STDIN": admission webhook "warden-validating.common-webhooks.networking.gke.io" denied the request:

===========================================================================
Workload Mismatches Found for Allowlist (example-allowlist-1):
===========================================================================
HostNetwork Mismatch: Workload=true, Allowlist=false
HostPID Mismatch: Workload=true, Allowlist=false
Volume[0]: data
         - data not found in allowlist. Verify volume with matching name exists in allowlist.
Container[0]:
- Envs Mismatch:
        - env[0]: 'ENV_VAR1' has no matching string or regex pattern in allowlist.
        - env[1]: 'ENV_VAR2' has no matching string or regex pattern in allowlist.
- Image Mismatch: Workload=k8s.gcr.io/diff/image, Allowlist=k8s.gcr.io/pause2. Verify that image string or regex match.
- SecurityContext:
        - Capabilities.Add Mismatch: the following added capabilities are not permitted by the allowlist: [SYS_ADMIN SYS_PTRACE]
- VolumeMount[0]: data
        - data not found in allowlist. Verify volumeMount with matching name exists in allowlist.

    Dans cet exemple, les cas de non-respect suivants se produisent :

    • La charge de travail spécifie hostNetwork: true, mais la liste d'autorisation ne spécifie pas hostNetwork: true.
    • La charge de travail spécifie hostPID: true, mais la liste d'autorisation ne spécifie pas hostPID: true.
    • La charge de travail spécifie un volume nommé data, mais la liste d'autorisation ne spécifie pas de volume nommé data.
    • Le conteneur spécifie des variables d'environnement nommées ENV_VAR1 et ENV_VAR2, mais la liste d'autorisation ne les spécifie pas.
    • Le conteneur spécifie l'image k8s.gcr.io/diff/image, mais la liste d'autorisation spécifie k8s.gcr.io/pause2.
    • Le conteneur ajoute les capacités SYS_ADMIN et SYS_PTRACE, mais la liste d'autorisation n'autorise pas l'ajout de ces capacités.
    • Le conteneur spécifie un montage de volume nommé data, mais la liste d'autorisation ne spécifie pas de montage de volume nommé data.

Si vous déployez une charge de travail appartenant à un fournisseur tiers, ouvrez un problème avec ce fournisseur pour résoudre les cas de non-respect. Indiquez le résultat de l'étape précédente dans le problème.

Version de GKE incompatible

GKE peut refuser une charge de travail si la liste d'autorisation spécifie une version GKE minimale ultérieure à la version GKE du cluster.

  1. Vérifiez si la liste d'autorisation spécifie une version GKE minimale :

    kubectl describe workloadallowlist ALLOWLIST_NAME | grep "minGKEVersion"

    Remplacez ALLOWLIST_NAME par le nom de la liste d'autorisation.

    Si le résultat est vide, la liste d'autorisation ne spécifie pas de version GKE minimale. Vous pouvez ignorer cette section. Si la sortie est une valeur, la liste d'autorisation spécifie une version GKE minimale.

  2. Vérifiez la version GKE du cluster :

    gcloud container clusters describe CLUSTER_NAME \
    --location=CLUSTER_LOCATION \
    --format="value(currentMasterVersion)"

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster.
    • CLUSTER_LOCATION : Google Cloud emplacement du cluster.

    Le résultat ressemble à ce qui suit :

    1.32.3-gke.1006000

  3. Si la version GKE du cluster est antérieure à la version GKE minimale de la liste d'autorisation, mettez à niveau le cluster vers la version GKE minimale de la liste d'autorisation ou une version ultérieure. Pour en savoir plus, consultez Mettre à niveau le cluster.

Une fois la mise à niveau terminée, essayez de déployer la charge de travail sur le cluster.

Incohérences de chaînes

Des champs spécifiques de la spécification WorkloadAllowlist doivent correspondre exactement aux chaînes des champs correspondants de la spécification de la charge de travail.

  1. Ouvrez la page de référence de la définition de ressource personnalisée (CRD) WorkloadAllowlist.
  2. Pour chaque champ de la spécification WorkloadAllowlist, vérifiez si le CRD exige une correspondance exacte de la chaîne.

  3. Pour chaque champ nécessitant une correspondance exacte de la chaîne, vérifiez si la valeur de votre spécification WorkloadAllowlist correspond à la valeur correspondante dans votre spécification de charge de travail.

    Par exemple, chaque commande exécutée par un conteneur doit correspondre exactement à une commande de la liste d'autorisation. Toute différence par rapport à la commande exacte entraînera un refus.

En cas d'incohérence, mettez à jour votre spécification WorkloadAllowlist pour qu'elle corresponde à votre spécification de charge de travail.

Incohérences d'expressions régulières

Des champs spécifiques de la spécification WorkloadAllowlist sont compatibles avec la correspondance des expressions régulières.

  1. Dans la spécification WorkloadAllowlist, recherchez les champs qui spécifient des expressions régulières.

  2. Assurez-vous que la syntaxe de l'expression régulière est correcte. Le CRD WorkloadAllowlist est compatible avec la syntaxe d'expression régulière Google RE2. Vérifiez que vos expressions présentent les propriétés suivantes :

    • L'expression régulière commence par le caractère ^ et se termine par le caractère $. Exemple : ^example-auth\.google\.com\/go_[a-z0-9]+\/google\/path$.
    • Chaque caractère spécial est échappé avec le caractère d'échappement \. Recherchez les caractères \ en trop ou manquants.
    • Les chemins d'accès aux images dans la liste d'autorisation n'incluent pas de tags ni de condensés. Par exemple, utilisez k8s.gcr.io/pause au lieu de k8s.gcr.io/pause:3.1 ou k8s.gcr.io/pause@sha256:1234567890.

Après avoir résolu les problèmes liés aux expressions régulières, essayez de déployer votre charge de travail sur le cluster.

Échapper les caractères dans les commandes et les arguments

GKE ne peut pas faire correspondre les commandes et les arguments si vous n'échappez pas les caractères spéciaux. Les exigences concernant l'échappement des caractères dépendent de la façon dont vous appliquez la liste d'autorisation. Par exemple, l'application d'une liste d'autorisation en tant que fichier YAML ou JSON présente des exigences d'échappement différentes de celles de la création d'une spécification de liste d'autorisation à l'aide d'un outil de ligne de commande. Cette section décrit les exigences d'échappement pour les fichiers YAML.

Échappez tous les caractères spéciaux dans les champs commands et args de la spécification WorkloadAllowlist, même si vous n'utilisez pas d'expression régulière. Pour échapper les caractères spéciaux, utilisez le caractère \, comme dans les exemples suivants :

  • Commande : kubectl describe \$\{POD_NAME\}
  • Argument : hostname \$NODE_NAME; dcgm-exporter --remote-hostengine-info \$\(NODE_IP\) --collectors /etc/dcgm-exporter/counters.csv

Interférence des Webhooks avec les charges de travail figurant sur une liste d'autorisation

Dans certains cas, même si une charge de travail est correctement configurée pour correspondre à une liste d'autorisation, elle peut toujours être refusée par GKE. Cette situation peut se produire si un autre contrôleur d'admission (webhook) de votre cluster modifie les pods créés par le contrôleur de charge de travail après qu'ils ont été autorisés par la liste d'autorisation. Ces modifications peuvent entraîner une non-concordance entre la spécification du pod et la liste d'autorisation, ce qui peut entraîner un refus par le webhook d'admission GKE Warden.

Ce problème est courant avec les agents de surveillance et de sécurité tiers qui injectent des conteneurs side-car ou des variables d'environnement dans les pods.

Le symptôme le plus courant est que votre contrôleur de charge de travail (tel qu'un DaemonSet ou un déploiement) est créé avec succès, mais qu'il ne parvient pas à créer de pods. Lorsque vous inspectez les événements du contrôleur, vous voyez des messages indiquant que les pods ont été refusés par le webhook d'admission.

  1. Suivez la procédure décrite dans la section Problèmes de déploiement de charges de travail privilégiées pour ajouter le libellé cloud.google.com/matching-allowlist à votre charge de travail.
  2. Copiez spec.template à partir du fichier manifeste YAML de votre charge de travail.
  3. Créez un fichier manifeste de pod et collez la spécification copiée dans le champ spec.

  4. Définissez les champs apiVersion, kind et metadata.name dans le fichier manifeste de pod :

    apiVersion: v1
kind: Pod
metadata:
  name: POD_NAME
  labels:
    cloud.google.com/matching-allowlist: ALLOWLIST_NAME
spec:
  # Paste the content of spec.template here

    Remplacez les éléments suivants :

    • POD_NAME : nom de votre pod de test.
    • ALLOWLIST_NAME : nom de la liste d'autorisation.

  5. Appliquez le fichier manifeste de pod :

    kubectl apply -f YOUR_POD_MANIFEST_FILE

    Remplacez YOUR_POD_MANIFEST_FILE par le chemin d'accès à votre fichier manifeste de pod.

  6. Inspectez le résultat de l'étape précédente. Si vous voyez des champs inattendus dans la section "Incompatibilités de charge de travail", tels que des variables d'environnement supplémentaires (par exemple, DD_AGENT_HOST), des conteneurs ou des volumes, cela indique fortement qu'un autre webhook modifie vos pods.

Pour résoudre ce problème, vous devez configurer le webhook en conflit pour l'empêcher de modifier les pods de votre charge de travail autorisée. Pour ce faire, il suffit généralement d'ajouter un libellé ou une annotation à la charge de travail ou à son espace de noms pour indiquer au webhook qu'il doit être exclu de la mutation. Par exemple, avec Datadog, vous devez ajouter le libellé admission.datadoghq.com/enabled: "false" à l'espace de noms de votre charge de travail.

Consultez la documentation du logiciel tiers spécifique que vous utilisez pour savoir comment exclure des charges de travail de son contrôleur d'admission.

En empêchant l'autre webhook de modifier les pods, vous pouvez vous assurer qu'ils continuent de correspondre à la liste d'autorisation et qu'ils sont déployés avec succès sur votre cluster Autopilot.

Bugs et demandes de fonctionnalités pour les charges de travail privilégiées et les listes d'autorisation

Si vous exécutez une charge de travail privilégiée fournie par un partenaire GKE ou un fournisseur tiers, ce fournisseur est responsable de la création, du développement et de la maintenance de ses charges de travail privilégiées et de ses listes d'autorisation. Si vous rencontrez un bug ou si vous souhaitez demander une fonctionnalité pour une charge de travail ou une liste d'autorisation privilégiée d'un partenaire ou d'un tiers, contactez le fournisseur.

Étapes suivantes