Vérifier l'intégrité des VM du plan de contrôle GKE

Ce guide explique comment vérifier l'intégrité de l'image de machine virtuelle (VM) Compute Engine que Google Kubernetes Engine (GKE) utilise pour les VM du plan de contrôle. Ce guide est destiné à une équipe de sécurité qui surveille les journaux du plan de contrôle et souhaite vérifier les points suivants :

  • La VM du plan de contrôle a démarré avec un micrologiciel authentique et d'autres logiciels de démarrage qui ont été vérifiés de manière cryptographique par le démarrage sécurisé et la surveillance de l'intégrité.
  • La VM du plan de contrôle a démarré à partir d'une image GKE OS authentique.

Vous pouvez également effectuer cette vérification pour les images d'OS et l'intégrité du démarrage de vos nœuds de calcul.

Cette page décrit l'une des fonctionnalités facultatives du plan de contrôle dans GKE. Elle vous permet d'effectuer des tâches telles que la vérification de la stratégie de sécurité de votre plan de contrôle ou la configuration du chiffrement et de la signature des identifiants dans le plan de contrôle à l'aide de clés que vous gérez. Pour en savoir plus, consultez À propos de l'autorité du plan de contrôle GKE.

Par défaut, Trusted Cloud applique diverses mesures de sécurité au plan de contrôle géré. Cette page décrit les fonctionnalités facultatives qui vous offrent une visibilité ou un contrôle accrus sur le plan de contrôle GKE.

À propos de la validation de l'intégrité des VM

Par défaut, toutes les instances du plan de contrôle GKE sont des VM protégées, c'est-à-dire des VM renforcées qui utilisent des fonctionnalités de sécurité telles que le démarrage sécurisé et mesuré, un module de plate-forme virtuelle sécurisée (vTPM) et le micrologiciel UEFI. Tous les nœuds GKE activent également la surveillance de l'intégrité, qui valide la séquence de démarrage de chaque VM protégée par rapport à une séquence de démarrage de référence "correcte". Cette validation renvoie des résultats de réussite ou d'échec pour chaque phase de la séquence de démarrage et ajoute ces résultats à Cloud Logging. La surveillance de l'intégrité est activée par défaut dans tous les clusters GKE et valide les phases suivantes :

  • Séquence de démarrage précoce : du démarrage du micrologiciel UEFI jusqu'à la prise de contrôle du bootloader. Ajouté aux journaux de la VM en tant que earlyBootReportEvent.
  • Séquence de démarrage tardif : du moment où le bootloader prend le contrôle jusqu'à ce que le noyau du système d'exploitation prenne le contrôle. Ajouté aux journaux de la VM sous la forme lateBootReportEvent.

GKE ajoute également les journaux de création de VM du plan de contrôle à Logging. Ces journaux contiennent des métadonnées qui identifient la machine et incluent des informations sur l'image de VM et la séquence de démarrage.Trusted Cloud publie une attestation récapitulative de validation (VSA) pour chaque image de VM du plan de contrôle GKE dans le dépôt gke-vsa sur GitHub. Le VSA utilise le framework in-toto pour les attestations. Vous pouvez valider les journaux des VM du plan de contrôle de vos clusters par rapport aux VSA correspondants pour vérifier que vos nœuds du plan de contrôle ont démarré comme prévu.

Effectuer ces validations peut vous aider à atteindre les objectifs suivants :

  • Assurez-vous que le logiciel du plan de contrôle est protégé par le démarrage sécurisé et la surveillance de l'intégrité, qu'il correspond au code source prévu et qu'il est exactement identique à l'image utilisée par les autres clients Trusted Cloud .
  • Renforcez votre confiance dans la façon dont GKE sécurise le plan de contrôle.

Tarifs

Cette fonctionnalité est proposée sans frais supplémentaires dans GKE.

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.

  • Enable the Cloud Logging API.

    Enable the API

  • Assurez-vous de disposer d'un cluster en mode GKE Autopilot ou standard exécutant la version 1.29 ou ultérieure.

Rôles requis

Pour obtenir les autorisations nécessaires pour vérifier l'intégrité des VM du plan de contrôle, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre projet :

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.

Rechercher les phases de séquence de démarrage ayant échoué

La surveillance de l'intégrité ajoute un journal à Logging si une VM de plan de contrôle échoue ou termine correctement une phase de la séquence de démarrage. Pour afficher les événements de démarrage ayant échoué, exécutez les commandes suivantes :

  1. Dans la console Trusted Cloud , accédez à la page Explorateur de journaux.

    Accéder à l'explorateur de journaux

  2. Dans le champ Requête, saisissez la requête suivante :

    jsonPayload.@type="type.googleapis.com/cloud_integrity.IntegrityEvent"
jsonPayload.earlyBootReportEvent.policyEvaluationPassed="false" OR jsonPayload.lateBootReportEvent.policyEvaluationPassed="false"
jsonPayload.metadata.isKubernetesControlPlaneVM="true"

    Vous pouvez également vérifier les événements de démarrage réussis en remplaçant false par true dans cette requête.

  3. Cliquez sur Exécuter la requête. Si aucun résultat ne s'affiche, cela signifie que vos VM du plan de contrôle ont réussi tous les contrôles de surveillance de l'intégrité. Si vous voyez un résultat, passez à l'étape suivante pour identifier le cluster correspondant.

  4. Dans le journal d'intégrité du démarrage ayant échoué, copiez la valeur du champ resource.labels.instance_id.

  5. Dans le champ Requête, saisissez la requête suivante :

    protoPayload.@type="type.googleapis.com/google.cloud.audit.AuditLog"
protoPayload.metadata.isKubernetesControlPlaneVM="true"
resource.labels.instance_id="INSTANCE_ID"
protoPayload.methodName="v1.compute.instances.insert"

    Remplacez INSTANCE_ID par la valeur du champ instance_id de l'étape précédente.

  6. Cliquez sur Exécuter la requête. La valeur du champ protoPayload.metadata.parentResource.parentResourceId correspond à l'ID du cluster GKE.

  7. Recherchez le nom du cluster GKE :

    gcloud asset query \
    --organization=ORGANIZATION_ID \
    --statement="SELECT name FROM container_googleapis_com_Cluster WHERE resource.data.id='CLUSTER_ID';"

    Remplacez les éléments suivants :

    • ORGANIZATION_ID : ID numérique de votre organisationTrusted Cloud .
    • CLUSTER_ID : valeur du champ protoPayload.metadata.parentResource.parentResourceId de l'étape précédente.

    Le résultat ressemble à ce qui suit :

    # lines omitted for clarity
//container.googleapis.com/projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME

    Ce résultat comporte les champs suivants :

    • PROJECT_ID : ID de votre projet Trusted Cloud .
    • LOCATION : emplacement du cluster.
    • CLUSTER_NAME : nom du cluster.

Rechercher et inspecter les journaux de la VM du plan de contrôle

Les journaux de création de VM Compute Engine correspondant aux clusters GKE sont stockés dans le bucket de journaux _Default. Pour trouver les journaux de création de vos VM de plan de contrôle de cluster et récupérer ces métadonnées, procédez comme suit :

  1. Dans la console Trusted Cloud , accédez à la page Explorateur de journaux.

    Accéder à l'explorateur de journaux

  2. Dans le champ Requête, saisissez la requête suivante :

    resource.type="gce_instance"
protoPayload.methodName="v1.compute.instances.insert"
protoPayload.metadata.isKubernetesControlPlaneVM="true"

  3. Cliquez sur Exécuter la requête. Si aucun résultat ne s'affiche, vérifiez que vous remplissez toutes les conditions requises dans la section Avant de commencer.

  4. Dans les résultats de la requête, vérifiez le champ metadata. Le résultat ressemble à ce qui suit :

    # fields omitted for clarity
"metadata": {
  "usedResources": {
    "attachedDisks": [
      {
        "sourceImageId": "9046093115864736653",
        "sourceImage": "https://www.googleapis.com/compute/v1/projects/1234567890/global/images/gke-1302-gke1627000-cos-113-18244-85-49-c-pre",
        "isBootDisk": true
      }
# fields omitted for clarity

    Le champ metadata contient les informations suivantes :

    • usedResources : liste des ressources utilisées pour créer la VM.
    • attachedDisks : disque de démarrage de la VM.
    • sourceImageId : ID unique de l'image de VM.
    • sourceImage : URL de l'image de VM source. La syntaxe de la valeur de ce champ est https://www.googleapis.com/compute/v1/projects/PROJECT_NUMBER/global/images/IMAGE_NAME, où PROJECT_NUMBER est le numéro du projet appartenant àTrusted Cloudqui héberge les VM du plan de contrôle et IMAGE_NAME est le nom de l'image utilisée pour démarrer la VM.
    • isBootDisk : identifiant booléen indiquant si ce disque a été utilisé comme disque de démarrage pour la VM.

Rechercher et valider la VSA pour les images de VM du plan de contrôle

Dans cette section, vous trouverez le VSA qui correspond à votre image de VM de plan de contrôle dans le dépôt gke-vsa sur GitHub. Vous utilisez ensuite un outil nommé slsa-verifier fourni par le framework SLSA (Supply chain Levels for Software Artifacts) pour valider la VSA. Vous avez besoin des données suivantes du journal de création de la VM du plan de contrôle :

  • ID de l'image de VM
  • Numéro du projet appartenant à Trusted Cloudet hébergeant les VM
  • Nom de l'image d'OS utilisée pour démarrer la VM

Le fichier correspondant à votre VM de plan de contrôle présente le format de nom de fichier suivant :

IMAGE_NAME:IMAGE_ID.intoto.jsonl

Remplacez les éléments suivants :

  • IMAGE_NAME : nom de l'image de VM, qui correspond à la chaîne après /images/ dans le champ attachedDisks.sourceImage du journal d'audit de la VM de la section précédente. Par exemple, gke-1302-gke1627000-cos-113-18244-85-49-c-pre.
  • IMAGE_ID : ID de l'image de VM, qui correspond à la valeur du champ attachedDisks.sourceImageId dans le journal d'audit de la VM de la section précédente. Exemple : 9046093115864736653.

Pour trouver et valider le fichier VSA lorsque vous connaissez son nom, procédez comme suit :

  1. Ouvrez le dépôt GitHub gke-vsa.
  2. Dans le répertoire "gke-master-images", recherchez le fichier correspondant à votre image de VM. Par exemple, https://github.com/GoogleCloudPlatform/gke-vsa/blob/main/gke-master-images:78064567238/IMAGE_NAME:IMAGE_ID.intoto.jsonl.
  3. Téléchargez le fichier VSA.
  4. Installez l'outil slsa-verifier.

  5. Enregistrez la clé publique permettant de valider la VSA dans un fichier nommé vsa_signing_public_key :

    -----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEeGa6ZCZn0q6WpaUwJrSk+PPYEsca
3Xkk3UrxvbQtoZzTmq0zIYq+4QQl0YBedSyy+XcwAMaUWTouTrB05WhYtg==
-----END PUBLIC KEY-----

  6. Vérifiez le VSA :

    slsa-verifier verify-vsa \
    --attestation-path=PATH_TO_VSA_FILE \
    --resource-uri=gce_image://gke-master-images:IMAGE_NAME \
    --subject-digest=gce_image_id:IMAGE_ID\
    --verifier-id=https://bcid.corp.google.com/verifier/bcid_package_enforcer/v0.1 \
    --verified-level=BCID_L1 \
    --verified-level=SLSA_BUILD_LEVEL_2 \
    --public-key-path=PATH_TO_PUBLIC_KEY_FILE \
    --public-key-id=keystore://76574:prod:vsa_signing_public_key

    Remplacez les éléments suivants :

    • PATH_TO_VSA_FILE : chemin d'accès au fichier VSA que vous avez téléchargé.
    • IMAGE_NAME : nom de l'image de VM, comme gke-1302-gke1627000-cos-113-18244-85-49-c-pre.
    • IMAGE_ID : ID de l'image de VM, par exemple 9046093115864736653.

    Si le VSA réussit les vérifications, le résultat est le suivant :

    Verifying VSA: PASSED
PASSED: SLSA verification passed

Étapes suivantes