Isoler des charges de travail dans des pools de nœuds dédiés

Partagé Standard

Les pools de nœuds dédiés dans Google Distributed Cloud (GDC) sous air gap vous permettent d'isoler les charges de travail de conteneurs pour renforcer la sécurité du cluster Kubernetes et contrôler l'emplacement des pods. Cette séparation permet de réduire le risque d'attaques par élévation des privilèges. Pour configurer des pools dédiés, vous appliquez des rejets et des étiquettes, vous les faites correspondre aux tolérances de charge de travail et aux règles d'affinité de nœuds, puis vous vérifiez la planification.

Ce document s'adresse aux administrateurs informatiques du groupe d'administrateurs de plate-forme qui gèrent les clusters Kubernetes et aux développeurs du groupe d'opérateurs d'applications qui exécutent des conteneurs. Pour en savoir plus, consultez Présentation de l'isolation des nœuds et Audiences pour la documentation GDC sous air gap.

Avant de commencer

Pour effectuer les tâches décrites dans ce document, vous devez demander les autorisations nécessaires et préparer votre environnement.

Demander des rôles IAM

Vous devez disposer de rôles spécifiques pour obtenir les autorisations nécessaires pour isoler les charges de travail de conteneur dans votre cluster Kubernetes. Les rôles dont vous avez besoin dépendent de l'environnement dans lequel vous travaillez : un cluster partagé au niveau de l'organisation ou un cluster standard au niveau du projet. Pour en savoir plus, consultez Configurations de clusters Kubernetes.

Rôles de cluster partagés

Contactez l'administrateur de l'organisation IAM pour demander les rôles suivants afin de marquer et d'étiqueter un pool de nœuds dans un cluster partagé :

• Administrateur de cluster d'utilisateur (user-cluster-admin) : créez, supprimez, modifiez ou affichez les ressources d'un cluster partagé hébergé sur le serveur de l'API Management. Ce rôle permet d'accéder aux pools de nœuds du cluster partagé.

• Développeur de cluster d'utilisateur (user-cluster-developer) : créer, supprimer, modifier ou afficher un cluster partagé. Ce rôle permet d'accéder aux API du plan de données hébergées dans le cluster partagé.

Ces rôles ne sont pas liés à un espace de noms.

Rôles de cluster standards

Contactez l'administrateur de projet IAM pour demander les rôles suivants afin d'appliquer un rejet et une étiquette à un pool de nœuds dans un cluster standard :

• Administrateur de cluster (cluster-admin) : créez, supprimez, modifiez ou affichez toutes les ressources d'un cluster standard. Ce rôle permet d'accéder aux API du plan de données hébergées dans le cluster standard qui régissent les ressources du cluster.

• Développeur de cluster (cluster-developer) : créer, supprimer, modifier ou afficher un cluster standard. Ce rôle permet d'accéder aux API du plan de données hébergées dans le cluster standard qui gère le cluster.

• Administrateur de cluster standard (standard-cluster-admin) : crée, supprime, modifie ou affiche les ressources d'un cluster standard hébergé sur le serveur de l'API Management. Ce rôle permet d'accéder aux pools de nœuds du cluster standard.

Ces rôles sont liés à l'espace de noms de votre projet.

Préparer votre environnement

Pour exécuter des commandes sur un cluster Kubernetes à l'aide de l'API, assurez-vous de disposer des ressources suivantes :

• Connectez-vous et générez le fichier kubeconfig pour le cluster Kubernetes.

• Utilisez le chemin d'accès kubeconfig du cluster Kubernetes pour remplacer KUBERNETES_CLUSTER_KUBECONFIG dans ces instructions.

• Connectez-vous et générez le fichier kubeconfig pour le serveur d'API de gestion.

• Utilisez le chemin d'accès kubeconfig du serveur d'API Management pour remplacer MANAGEMENT_API_SERVER dans ces instructions.

• Choisissez un nom spécifique pour le rejet de nœud et le libellé de nœud que vous souhaitez utiliser pour les pools de nœuds dédiés. Par exemple, workloadType=untrusted.

Ajouter un rejet et un libellé à un nouveau pool de nœuds

Lorsque vous appliquez un rejet ou une étiquette à un nouveau pool de nœuds, tous les nœuds, y compris ceux ajoutés ultérieurement, reçoivent automatiquement les rejets et les étiquettes spécifiés. Vous ne pouvez pas supprimer un rejet ou une étiquette d'un pool de nœuds après son application.

Remarque : Pour appliquer un rejet ou un libellé à un pool de nœuds existant, vous devez appliquer manuellement la modification à chaque nœud existant. Les rejets et les libellés ne sont pas propagés automatiquement à tous les nœuds d'un pool de nœuds existant. Pour en savoir plus, consultez Appliquer un rejet et un libellé à un pool de nœuds existant.

Pour ajouter un rejet et un libellé à un nouveau pool de nœuds, procédez comme suit :

1. Modifiez la section nodePools de la ressource personnalisée Cluster directement lors de la création du pool de nœuds :

   nodePools:
     # Several lines of code are omitted here.
     - machineTypeName: n2-standard-2-gdc
       name: nodepool-1
       nodeCount: 3
       taints:
       - key: "TAINT_KEY"
         value: "TAINT_VALUE"
         effect: "TAINT_EFFECT"
       labels:
         LABEL_KEY: LABEL_VALUE
   

   Remplacez les éléments suivants :

   • TAINT_KEY : partie clé du rejet de la paire clé-valeur associée à un TAINT_EFFECT de planification. Par exemple, workloadType.
   • TAINT_VALUE : partie valeur du rejet de la paire clé-valeur associée à un TAINT_EFFECT de planification. Par exemple, untrusted.
   • TAINT_EFFECT : l'une des valeurs d'effet suivantes :
     • NoSchedule : les pods qui ne tolèrent pas ce rejet ne sont pas programmés sur le nœud ; les pods existants ne sont pas expulsés du nœud.
     • PreferNoSchedule : Kubernetes évite de programmer les pods qui ne tolèrent pas ce rejet sur le nœud.
     • NoExecute : si le pod est déjà en cours d'exécution sur le nœud, il est expulsé de celui-ci. Dans le cas contraire, il n'est pas programmé sur le nœud.
   • LABEL_KEY: LABEL_VALUE : paires clé/valeur pour les libellés de nœud, qui correspondent aux sélecteurs que vous spécifiez dans vos fichiers manifestes de charge de travail.

2. Appliquez la ressource Cluster pour créer le pool de nœuds :

   kubectl apply -f cluster.yaml --kubeconfig MANAGEMENT_API_SERVER
   

   Remplacez MANAGEMENT_API_SERVER par le chemin d'accès du fichier kubeconfig pour le serveur d'API zonal où est hébergé le cluster Kubernetes.

Ajouter un rejet et un libellé à un pool de nœuds existant

Pour appliquer un rejet ou un libellé à un pool de nœuds existant, vous devez appliquer les modifications à chaque nœud existant. Vous ne pouvez pas mettre à jour dynamiquement les configurations de pool de nœuds.

Vous ne pouvez pas supprimer un rejet ou une étiquette d'un pool de nœuds après son application.

Pour ajouter un rejet et une étiquette à un pool de nœuds existant, procédez comme suit :

1. Répertoriez les nœuds du pool de nœuds dédié :

   kubectl get node --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG \
       -l baremetal.cluster.gke.io/node-pool=NODE_POOL_NAME
   

   Remplacez les variables suivantes :

   • KUBERNETES_CLUSTER_KUBECONFIG : chemin d'accès du fichier kubeconfig pour le cluster Kubernetes.
   • NODE_POOL_NAME : nom de votre pool de nœuds dédié.

   Notez l'ID de chaque nœud du pool de nœuds à partir du résultat.

2. Pour chaque nœud du pool de nœuds, appliquez les rejets :

   kubectl taint nodes NODE_ID \
       TAINT_KEY=TAINT_VALUE:TAINT_EFFECT \
       --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG
   

   Remplacez les variables suivantes :

   • NODE_ID : ID du nœud de calcul dans le pool de nœuds dédié.
   • TAINT_KEY=TAINT_VALUE : paire clé-valeur associée à un TAINT_EFFECT de planification. Exemple : workloadType=untrusted.
   • TAINT_EFFECT : l'une des valeurs d'effet suivantes :
     • NoSchedule : les pods qui ne tolèrent pas ce rejet ne sont pas programmés sur le nœud ; les pods existants ne sont pas expulsés du nœud.
     • PreferNoSchedule : Kubernetes évite de programmer les pods qui ne tolèrent pas ce rejet sur le nœud.
     • NoExecute : si le pod est déjà en cours d'exécution sur le nœud, il est expulsé de celui-ci. Dans le cas contraire, il n'est pas programmé sur le nœud.
   • KUBERNETES_CLUSTER_KUBECONFIG : chemin d'accès du fichier kubeconfig pour le cluster Kubernetes.

3. Pour chaque nœud du pool de nœuds, appliquez les étiquettes qui correspondent aux sélecteurs que vous allez définir dans vos charges de travail de conteneur :

   kubectl label NODE_ID \
       LABEL_KEY:LABEL_VALUE \
       --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG
   

   Remplacez les variables suivantes :

   • NODE_ID : ID du nœud de calcul dans le pool de nœuds dédié.
   • LABEL_KEY:LABEL_VALUE : paires clé/valeur pour les libellés de nœud, qui correspondent aux sélecteurs que vous spécifiez dans vos fichiers manifestes de charge de travail.
   • KUBERNETES_CLUSTER_KUBECONFIG : chemin d'accès du fichier kubeconfig pour le cluster Kubernetes.

Ajouter une tolérance et une règle d'affinité de nœuds

Une fois que vous avez ajouté un rejet au pool de nœuds dédié, aucune charge de travail ne peut y être programmée, à moins qu'elle ne dispose d'une tolérance correspondant au rejet que vous avez ajouté. Ajoutez la tolérance à la spécification de vos charges de travail afin de permettre la programmation de ces pods sur votre pool de nœuds rejeté.

Si vous avez attribué un libellé au pool de nœuds dédié, vous pouvez également ajouter une règle d'affinité de nœuds pour indiquer à GDC de ne planifier vos charges de travail que sur ce pool de nœuds.

Pour configurer votre charge de travail de conteneur afin qu'elle s'exécute dans le pool de nœuds dédié, procédez comme suit :

1. Ajoutez les sections suivantes à la section .spec.template.spec du fichier manifeste de votre charge de travail de conteneur, par exemple une ressource personnalisée Deployment :

   tolerations:
   - key: TAINT_KEY
     operator: Equal
     value: TAINT_VALUE
     effect: TAINT_EFFECT
   affinity:
     nodeAffinity:
       requiredDuringSchedulingIgnoredDuringExecution:
         nodeSelectorTerms:
         - matchExpressions:
           - key: LABEL_KEY
             operator: In
             values:
             - "LABEL_VALUE"
   

   Remplacez les éléments suivants :

   • TAINT_KEY : clé de rejet que vous avez appliquée à votre pool de nœuds dédié.
   • TAINT_VALUE : valeur de rejet que vous avez appliquée à votre pool de nœuds dédié.
   • TAINT_EFFECT : l'une des valeurs d'effet suivantes :
     • NoSchedule : les pods qui ne tolèrent pas ce rejet ne sont pas programmés sur le nœud ; les pods existants ne sont pas expulsés du nœud.
     • PreferNoSchedule : Kubernetes évite de programmer les pods qui ne tolèrent pas ce rejet sur le nœud.
     • NoExecute : si le pod est déjà en cours d'exécution sur le nœud, il est expulsé de celui-ci. Dans le cas contraire, il n'est pas programmé sur le nœud.
   • LABEL_KEY : clé de libellé de nœud que vous avez appliquée à votre pool de nœuds dédié.
   • LABEL_VALUE : valeur du libellé de nœud que vous avez appliquée à votre pool de nœuds dédié.

   Par exemple, la ressource Deployment suivante ajoute une tolérance au rejet workloadType=untrusted:NoExecute et une règle d'affinité de nœud pour le libellé de nœud workloadType=untrusted :

   kind: Deployment
   apiVersion: apps/v1
   metadata:
     name: my-app
     namespace: default
     labels:
       app: my-app
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: my-app
     template:
       metadata:
         labels:
           app: my-app
       spec:
         tolerations:
         - key: workloadType
           operator: Equal
           value: untrusted
           effect: NoExecute
         affinity:
           nodeAffinity:
             requiredDuringSchedulingIgnoredDuringExecution:
               nodeSelectorTerms:
               - matchExpressions:
                 - key: workloadType
                   operator: In
                   values:
                   - "untrusted"
         containers:
         - name: my-app
           image: harbor-1.org-1.zone1.google.gdc.test/harborproject/my-app
           ports:
           - containerPort: 80
         imagePullSecrets:
         - name: SECRET
   

2. Mettez à jour votre charge de travail de conteneur :

   kubectl apply -f deployment.yaml -n NAMESPACE \
       --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG
   

   Remplacez les variables suivantes :

   • NAMESPACE : espace de noms de votre charge de travail de conteneur. Pour les clusters partagés, il doit s'agir d'un espace de noms de projet. Pour les clusters standards, il peut s'agir de n'importe quel espace de noms.
   • KUBERNETES_CLUSTER_KUBECONFIG : chemin d'accès du fichier kubeconfig pour le cluster Kubernetes.

GDC recrée les pods concernés. La règle d'affinité de nœuds force l'application des pods sur le pool de nœuds dédié que vous avez créé. La tolérance ne permet de placer ces pods que sur les nœuds.

Vérifier que la séparation fonctionne

Vérifiez que les pods que vous avez désignés s'exécutent sur le pool de nœuds étiqueté.

• Répertoriez les pods dans l'espace de noms donné :

  kubectl get pods -o=wide -n NAMESPACE \
      --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG
  

  Remplacez les variables suivantes :

  • NAMESPACE : espace de noms de votre charge de travail de conteneur. Pour les clusters partagés, il doit s'agir d'un espace de noms de projet. Pour les clusters standards, il peut s'agir de n'importe quel espace de noms.
  • KUBERNETES_CLUSTER_KUBECONFIG : chemin d'accès du fichier kubeconfig pour le cluster Kubernetes.

  La sortie ressemble à ceci :

  pod/kube-abc-12tyuj
  pod/kube-abc-39oplef
  pod/kube-abc-95rzkap
  

  Vérifiez que vos charges de travail s'exécutent dans le pool de nœuds dédié.

Étapes suivantes

• Charges de travail de conteneur dans GDC
• Déployer une application de conteneur hautement disponible
• Charges de travail Kubernetes pour la haute disponibilité