Créer des listes d'autorisation pour les charges de travail privilégiées dans Autopilot

Autopilot

Ce document vous explique comment créer des listes d'autorisation qui vous permettent de déployer des charges de travail privilégiées dans vos nœuds Autopilot. Vous stockez ces listes d'autorisation dans des buckets Cloud Storage. Ce document s'adresse aux administrateurs et opérateurs de plate-forme qui souhaitent exempter des charges de travail spécifiques appartenant à des clients des contraintes de sécurité Autopilot par défaut pour des charges de travail Kubernetes spécifiques. Vous devez déjà connaître le contrôle des admissions des charges de travail privilégiées dans Autopilot.

À propos des charges de travail privilégiées dans Autopilot

Le mode Autopilot applique un ensemble de contraintes par défaut aux charges de travail pour améliorer votre niveau de sécurité. Vous pouvez contourner ces contraintes pour exécuter des charges de travail privilégiées spécifiques en installant des listes d'autorisation correspondant à ces charges de travail. Par défaut, tout cluster Autopilot ou Standard vous permet d'installer des listes d'autorisation provenant de partenaires Autopilot et de projets Open Source spécifiques.

Les clients GKE éligibles peuvent créer et gérer des listes d'autorisation pour leurs propres charges de travail privilégiées qui ne sont pas compatibles avec les contraintes Autopilot par défaut. Ces listes d'autorisation sont des ressources personnalisées Kubernetes WorkloadAllowlist que vous définissez dans des fichiers YAML et stockez dans des buckets Cloud Storage. Les administrateurs de l'authentification et des comptes utilisent les règles d'administration pour vous permettre de configurer vos clusters afin qu'ils reconnaissent ces listes d'autorisation et ces buckets gérés par le client. Les administrateurs de cluster peuvent installer ces listes d'autorisation pour que les charges de travail privilégiées puissent s'exécuter en mode Autopilot.

Pour en savoir plus sur le processus et les personnes impliquées, consultez Fonctionnement du contrôle des admissions des charges de travail Autopilot privilégiées.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

Activez l'API Google Kubernetes Engine.

Activer l'API Google Kubernetes Engine

Si vous souhaitez utiliser la Google Cloud CLI pour cette tâche, installez et initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.
Remarque : Pour les installations de la gcloud CLI existantes, veillez à définir la propriété compute/region. Si vous utilisez principalement des clusters zonaux, définissez plutôt compute/zone. En définissant un emplacement par défaut, vous pouvez éviter les erreurs gcloud CLI de ce type : One of [--zone, --region] must be supplied: Please specify location. Vous devrez peut-être spécifier l'emplacement dans certaines commandes si celui de votre cluster diffère de l'emplacement par défaut que vous avez défini.

Enable the Cloud Storage API.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.
Enable the API
Assurez-vous de disposer d'un cluster GKE exécutant la version 1.35 ou ultérieure. Vous pouvez également créer un cluster Autopilot pour cette tâche.
Vérifiez que vous disposez d'un bucket Cloud Storage que vous pouvez utiliser pour stocker les fichiers de la liste d'autorisation. Vous pouvez également créer un bucket pour cette tâche.
Ouvrez le fichier manifeste YAML qui définit la charge de travail privilégiée que vous souhaitez exécuter dans Autopilot.

Rôles requis

Pour obtenir les autorisations nécessaires pour stocker des listes d'autorisation dans Cloud Storage et configurer la synchronisation, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre bucket :

Stockez les listes d'autorisation dans votre bucket : Utilisateur d'objets de l'espace de stockage (roles/storage.objectUser)
Accorder l'accès à l'agent de service GKE : Administrateur Storage (roles/storage.admin)

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.

Créer et importer une WorkloadAllowlist

Les listes d'autorisation sont des ressources personnalisées WorkloadAllowlist que vous définissez dans des fichiers YAML. Les champs de la spécification d'une WorkloadAllowlist sont semblables à ceux d'une spécification de pod Kubernetes. Lorsque vous installez une liste d'autorisation dans votre cluster et que vous déployez une charge de travail privilégiée, GKE valide la spécification de la charge de travail privilégiée par rapport à la liste d'autorisation installée. La charge de travail ne peut s'exécuter que si tous les champs de la spécification de la liste d'autorisation correspondent aux champs correspondants de la spécification de la charge de travail.

Pour créer une liste WorkloadAllowlist et l'importer dans votre bucket Cloud Storage, procédez comme suit :

Identifiez la charge de travail privilégiée à ajouter à la liste d'autorisation.
Ajoutez l'annotation suivante au champ metadata.annotations de la spécification de votre pod :
```
cloud.google.com/generate-allowlist: "true"
```
Pour les pods gérés par un contrôleur, tel qu'un DaemonSet ou un déploiement, ajoutez l'annotation au champ spec.template.metadata.annotations.

Essayez de créer la charge de travail privilégiée dans votre cluster :

kubectl apply -f WORKLOAD_FILE_PATH

Remplacez WORKLOAD_FILE_PATH par le chemin d'accès à votre fichier manifeste de charge de travail. GKE rejette la charge de travail avec un message d'erreur qui inclut un fichier manifeste WorkloadAllowlist. Le résultat ressemble à ce qui suit :

This workload can be enabled using the following Custom Resource. To be used in-cluster, the WorkloadAllowlist must be uploaded to Google Cloud Storage and then installed using an AllowlistSynchronizer. Refer to https://cloud.google.com/kubernetes-engine/docs/how-to/autopilot-privileged-allowlists.

Note that many common partner workloads are already allowlisted. These can be installed directly using an AllowlistSynchronizer. Refer to https://cloud.google.com/kubernetes-engine/docs/resources/autopilot-partners.
---
apiVersion: auto.gke.io/v1
kind: WorkloadAllowlist
metadata:
    name: test-pod-allowlist-2025-09-11t22-40-37
    annotations:
        autopilot.gke.io/no-connect: "true"
exemptions:
    - autogke-disallow-privilege
matchingCriteria:
    containers:
        - name: pause-container2
          image: k8s.gcr.io/pause2
          securityContext:
            privileged: true

Dans un éditeur de texte, créez un fichier YAML contenant la WorkloadAllowlist générée.

Bonne pratique :
Utilisez un système de gestion des versions pour vos fichiers de liste d'autorisation. Les fichiers versionnés vous aident à conserver des noms de fichiers uniques dans le bucket.
Définissez le champ metadata.name de la liste d'autorisation.
Bonne pratique :
Définissez le nom de la liste d'autorisation sur la même valeur que le nom de fichier. Cette pratique garantit que le nom de la liste d'autorisation est unique dans votre bucket Cloud Storage. Tenter d'installer plusieurs listes d'autorisation portant le même nom peut entraîner un comportement inattendu.
Facultatif : Généralisez la WorkloadAllowlist afin qu'elle puisse exempter des charges de travail similaires. Pour ce faire, utilisez une des méthodes suivantes :
- Certains champs acceptent les expressions régulières, comme matchingCriteria.containers[*].image et matchingCriteria.containers[*].args. Utilisez une expression régulière qui correspond à plusieurs valeurs dans différentes charges de travail.
- Des champs spécifiques, tels que matchingCriteria.containers et matchingCriteria.securityContext.capabilities.add, correspondent à n'importe quelle charge de travail avec un sous-ensemble des valeurs de WorkloadAllowlist. Dans WorkloadAllowlist, spécifiez des valeurs supplémentaires pour correspondre à d'autres charges de travail.
Pour en savoir plus sur tous les champs et valeurs compatibles que vous pouvez utiliser, consultez la définition de ressource personnalisée WorkloadAllowlist.
Importez le fichier manifeste dans votre bucket Cloud Storage.

Si les règles de votre organisation autorisent l'installation de listes d'autorisation à partir de votre bucket dans les clusters, les administrateurs de cluster peuvent effectuer les opérations suivantes :

Ajoutez les chemins de votre liste d'autorisation à un cluster.
Créez un AllowlistSynchronizer pour installer les listes d'autorisation à partir de votre bucket.

Pour savoir comment configurer un cluster et installer des listes d'autorisation, consultez Contrôler l'admission des charges de travail privilégiées en mode Autopilot.

Exemple de configuration de la liste d'autorisation

Le champ matchingCriteria d'une spécification WorkloadAllowlist a une structure semblable à celle de la spécification de pod Kubernetes. La définition de ressource personnalisée WorkloadAllowlist est la source de vérité pour tous les champs, valeurs et expressions que vous pouvez utiliser.

Cette section vous présente un exemple de liste d'autorisation correspondant à une charge de travail présentant les propriétés suivantes :

Le conteneur container-1 de la charge de travail s'exécute en mode privilégié.
La charge de travail installe le répertoire /var/log/ à partir du système de fichiers du nœud en mode écriture.

Examinez l'exemple de charge de travail :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-privileged-workload
  labels:
    env: dev
spec:
  selector:
    matchLabels:
      env: dev
  template:
    metadata:
      labels:
        env: dev
    spec:
      containers:
      - name: container-1
        image: example-image-1
        resources:
          requests:
            cpu: "400m"
            memory: "4Gi"
        # Run the container in privileged mode
        securityContext:
          privileged: true
      - name: container-2
        image: example-image-2
        volumeMounts:
        - name: write-varlog
          mountPath: /logs
          readOnly: false
      # Mount a host directory
      volumes:
      - name: write-varlog
        hostPath:
          path: /var/log
          type: Directory

Par défaut, Autopilot rejette cette charge de travail.

Examinez l'exemple de WorkloadAllowlist :

apiVersion: auto.gke.io/v1
kind: WorkloadAllowlist
minGKEVersion: 1.32.0-gke.1000000
metadata:
  name: example-privileged-workload
  annotations:
    autopilot.gke.io/no-connect: "true"
# List of constraints that the allowlist modifies
exemptions:
- autogke-disallow-privilege
- autogke-no-write-mode-hostpath
matchingCriteria:
  containers:
  - name: container-1
    image: example-image-1
    securityContext:
      privileged: true
  - name: container-2
    image: example-image-2
    volumeMounts:
    - name: write-varlog
      mountPath: /logs
      readOnly: false
  volumes:
  - name: write-varlog
    hostPath:
      path: /var/log

Cette WorkloadAllowlist possède les propriétés suivantes :

Les valeurs du champ exemptions spécifient les contraintes Autopilot que la liste d'autorisation contourne.
Les valeurs du champ matchingCriteria spécifient les conteneurs utilisés par l'exemple de charge de travail et les champs qui enfreindraient normalement les contraintes Autopilot.

La liste d'autorisation ne contient que les valeurs des champs qui ne respectent pas les contraintes. Les autres champs de la charge de travail, tels que le champ resources.requests, sont ignorés.

Lorsque vous installez cet exemple de WorkloadAllowlist dans un cluster, GKE autorise l'exécution de la charge de travail privilégiée dans ce cluster. Par exemple, dans un cluster Standard comportant des nœuds Autopilot, l'installation de cette WorkloadAllowlist permet à la charge de travail privilégiée de s'exécuter sur les nœuds Autopilot.

Accorder l'accès à l'agent de service GKE

Pour synchroniser les listes d'autorisation de votre bucket dans un cluster, l'agent de service GKE du projet de cluster doit disposer des rôles IAM suivants :

Lecteur de buckets Storage (roles/storage.bucketViewer)
Lecteur d'objets de l'espace de stockage (roles/storage.objectViewer)

Pour accorder ces rôles à l'agent de service, procédez comme suit :

Recherchez le numéro de projet de votre cluster :

gcloud projects describe CLUSTER_PROJECT_ID \
    --format='value(projectNumber)'

Attribuez le rôle roles/storage.bucketViewer :
```
gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME
    --member=serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
    --project=BUCKET_PROJECT_ID \
    --role=roles/storage.bucketViewer
```
Remplacez les éléments suivants :
- BUCKET_NAME : nom de votre bucket Cloud Storage.
- CLUSTER_PROJECT_NUMBER : numéro du projet de cluster, issu de la sortie de l'étape précédente.
- BUCKET_PROJECT_ID : ID du projet contenant votre bucket.

Attribuez le rôle roles/storage.objectViewer :

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME
    --member=serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
    --project=BUCKET_PROJECT_ID \
    --role=roles/storage.objectViewer