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 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

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.

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 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 correspondaient 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 fonctionnalités SYS_ADMIN et SYS_PTRACE, mais la liste d'autorisation n'autorise pas l'ajout de ces fonctionnalité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.

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 privilégiées et leurs listes d'autorisation. 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