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 permet de protéger certaines métadonnées système potentiellement sensibles contre les charges de travail d'utilisateur exécutées sur votre cluster.

Vous pouvez activer la dissimulation de métadonnées pour empêcher les pods des utilisateurs d'accéder à certaines métadonnées de VM se rapportant aux nœuds de votre cluster, telles que les identifiants Kubelet et les informations sur les instances de VM. Plus précisément, la dissimulation de métadonnées protège l'accès à kube-env (qui contient les identifiants Kubelet) et au jeton d'identité d'instance.

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.

Vous ne pouvez activer la dissimulation de métadonnées que lors de la création d'un cluster ou de l'ajout d'un pool de nœuds à un cluster existant.

Limites

  • 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).

Créer un cluster ou un pool de nœuds avec dissimulation de métadonnées

Après avoir créé un compte de service, vous pouvez créer un cluster ou un pool de nœuds avec la fonctionnalité de dissimulation des métadonnées activée, à l'aide de Google Cloud CLI.

Créer un cluster

Pour créer un cluster avec la dissimulation de métadonnées activée, exécutez la commande suivante :

gcloud beta container clusters create CLUSTER_NAME \
  --workload-metadata-from-node=SECURE \
  --service-account=$NODE_SA_EMAIL

Remplacez CLUSTER_NAME par le nom de votre nouveau cluster.

L'option --workload-metadata-from-node prend les valeurs suivantes :

  • SECURE: active la dissimulation de métadonnées.
  • EXPOSED ou UNSPECIFIED : désactive la dissimulation de métadonnées.

Créer un pool de nœuds

Pour créer un pool de nœuds avec la dissimulation de métadonnées activée, exécutez la commande suivante :

gcloud beta container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --workload-metadata-from-node=SECURE \
  --service-account=$NODE_SA_EMAIL

Remplacez NODE_POOL_NAME par le nom du nouveau pool de nœuds.

Vérifier que les métadonnées de jeton d'identité sont dissimulées pour la charge de travail du cluster

Lorsque vous dissimulez des métadonnées, il ne doit pas être possible de demander une signature via le jeton d'identité d'instance du nœud. Pour vérifier que les requêtes informent explicitement les utilisateurs des métadonnées dissimulées, procédez comme suit :

  1. Ouvrez une session d'interface système dans un nouveau pod :

    kubectl run metadata-concealment -it --image=google/cloud-sdk:slim -- /bin/bash
    
  2. Dans le pod, essayez d'obtenir un point de terminaison dissimulé :

    curl -H "Metadata-Flavor: Google" \
    'http://metadata/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://www.example.com'
    

    Le résultat ressemble à ce qui suit :

    This metadata endpoint is concealed.
    

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