Protéger les métadonnées d'un cluster

Google Kubernetes Engine (GKE) utilise des métadonnées d'instance pour configurer les machines virtuelles (VM) de nœuds. Cependant, certaines de ces métadonnées sont potentiellement sensibles et doivent être protégées des charges de travail exécutées sur le cluster.

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 Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.

Configurer le compte de service des nœuds

Les identifiants du compte de service de chaque nœud continuent d'être exposés aux charges de travail. Par défaut, vos nœuds utilisent le compte de service par défaut Compute Engine. Vous devez configurer un compte de service à privilèges minimaux pour que vos nœuds puissent les utiliser à la place du compte de service Compute Engine par défaut. Associez ensuite ce compte de service à vos nœuds, de sorte qu'un pirate informatique ne puisse pas contourner les protections de métadonnées GKE en utilisant l'API Compute Engine pour accéder directement aux instances de VM sous-jacentes.

Pour en savoir plus, consultez la section Utiliser le principe du moindre privilège pour les comptes de service Google.

Pour créer un compte de service de nœud associé à des privilèges minimaux, procédez comme suit :

  1. Créez un compte de service Identity and Access Management (IAM), puis enregistrez l'adresse e-mail dans une variable d'environnement :

    gcloud iam service-accounts create NODE_SA_NAME \
    --display-name="DISPLAY_NAME"
export NODE_SA_EMAIL=$(gcloud iam service-accounts list --format='value(email)' \
    --filter='displayName:DISPLAY_NAME')

    Remplacez les éléments suivants :

    • NODE_SA_NAME: nom du nouveau compte de service de votre nœud.
    • DISPLAY_NAME : nom à afficher du nouveau compte de service.

    L'adresse e-mail du compte de service du nœud est au format NODE_SA_NAME@PROJECT_ID.iam.gserviceaccount.com.

  2. Configurez votre compte de service avec les rôles et les autorisations minimaux pour exécuter vos nœuds GKE :

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$NODE_SA_EMAIL \
    --role=roles/monitoring.metricWriter
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$NODE_SA_EMAIL \
    --role=roles/monitoring.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$NODE_SA_EMAIL \
    --role=roles/logging.logWriter

    Remplacez PROJECT_ID par l'ID de votre projet Google Cloud .

    De plus, si votre cluster extrait des images privées d'Artifact Registry, ajoutez le rôle roles/artifactregistry.reader :

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:$NODE_SA_EMAIL \
    --role=roles/artifactregistry.reader

Dissimuler des métadonnées

La dissimulation de métadonnées de GKE empêche les pods des utilisateurs d'accéder à kube-env, qui contient les identifiants Kubelet, et au jeton d'identité d'instance de la VM.

La dissimulation de métadonnées joue le rôle de pare-feu n'autorisant que les requêtes sécurisées dans le trafic allant des pods d'utilisateur (c'est-à-dire les pods non exécutés sur HostNetwork) au serveur de métadonnées du cluster. Ce pare-feu empêche les pods d'utilisateur d'exploiter les identifiants Kubelet pour des attaques d'élévation des privilèges, ou les identifiants de la VM pour des attaques d'élévation d'instance.

La fédération d'identité de charge de travail pour GKE se substitue à la nécessité d'utiliser la dissimulation de métadonnées et renforce les protections qu'elle offre. Dans tous les cas, vous devez utiliser la fédération d'identité de charge de travail pour GKE au lieu de la dissimulation des métadonnées. Pour en savoir plus, consultez À propos de la fédération d'identité de charge de travail pour GKE.

Pour activer la dissimulation de métadonnées, utilisez l'option --workload-metadata=SECURE obsolète dans votre commande gcloud beta container clusters create ou dans votre commande gcloud beta container node-pools create.

Limites

La dissimulation des métadonnées présente des limites, par exemple :

  • La dissimulation de métadonnées ne protège l'accès qu'à kube-env et au jeton d'identité d'instance du nœud.
  • La dissimulation de métadonnées ne limite pas l'accès au compte de service du nœud.
  • La dissimulation de métadonnées ne limite pas l'accès à d'autres métadonnées d'instance associées.
  • La dissimulation de métadonnées ne limite pas l'accès à d'autres anciennes API de métadonnées.
  • La dissimulation de métadonnées ne limite pas le trafic provenant des pods exécutés sur le réseau hôte (hostNetwork: true dans la spécification de pod).

Désactiver les anciennes API de métadonnées et effectuer une migration

Les points de terminaison du serveur de métadonnées Compute Engine v0.1 et v1beta1 sont obsolètes et ont été arrêtés le 30 septembre 2020.

Pour connaître le calendrier d'arrêt, consultez la page Abandon des points de terminaison du serveur de métadonnées v0.1 et v1beta1.

Étapes suivantes