Résoudre les problèmes de déploiement des charges de travail 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 pourquoi 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

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 fournie par 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.

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

Dans certains cas, même si une charge de travail est correctement configurée pour correspondre à une liste d'autorisations, 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 entraîne 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.

Problème constaté

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.

Diagnostic

  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 le spec.template à partir du fichier manifeste YAML de votre charge de travail.
  3. Créez un fichier manifeste de pod et collez-y 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.

Solution

Pour résoudre ce problème, vous devez configurer le webhook en conflit afin de 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

Il incombe aux partenaires de créer, de développer et de gérer leurs charges de travail et leurs listes d'autorisation privilégiées. Si vous rencontrez un bug ou si vous souhaitez demander une fonctionnalité pour une charge de travail privilégiée ou une liste d'autorisation, contactez le partenaire correspondant.

Étapes suivantes