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

Vous pouvez 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. Cette page fournit des instructions à l'intention d'une équipe de sécurité qui surveille les journaux du plan de contrôle pour 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é validé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 d'OS GKE authentique.

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

Cette page décrit une partie d'un ensemble de fonctionnalités facultatives du plan de contrôle dans GKE qui vous permettent d'effectuer des tâches telles que la vérification de votre niveau de sécurité du 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, Google 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 plus de visibilité ou de contrôle 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, qui sont des VM renforcées qui utilisent des fonctionnalités de sécurité telles que le démarrage mesuré et sécurisé, un module vTPM (Virtual Trusted Platform Module) 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 "correcte" de référence. 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ée aux journaux de la VM en tant que earlyBootReportEvent.
  • Séquence de démarrage tardif : de la prise de contrôle du bootloader jusqu'à la prise de contrôle du noyau du système d'exploitation. Ajoutée aux journaux de la VM en tant que lateBootReportEvent.

GKE ajoute également des 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 la VM et la séquence de démarrage. Google Cloud publie une attestation de résumé de validation (VSA) pour chaque image de VM du plan de contrôle GKE dans le dépôt gke-vsa sur GitHub. La VSA utilise le framework in-toto pour les attestations. Vous pouvez valider les journaux de VM du plan de contrôle de vos clusters par rapport aux VSA correspondantes pour vérifier que vos nœuds de plan de contrôle ont démarré comme prévu.

Ces validations peuvent 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 d'autres Google Cloud clients.
  • Améliorez 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 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.

  • Activez l'API Cloud Logging.

    Rôles requis pour activer les API

    Pour activer les API, vous avez besoin du rôle IAM Administrateur d'utilisation du service (roles/serviceusage.serviceUsageAdmin), qui contient l'autorisation serviceusage.services.enable. Découvrez comment attribuer des rôles.

    Activer l'API

  • Assurez-vous de disposer d'un cluster GKE en mode 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é de la 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 du 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 Google Cloud console, 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 rechercher 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 un résultat s'affiche, 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 Google Cloud organisation.
    • 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 Google Cloud projet.
    • LOCATION : emplacement du cluster.
    • CLUSTER_NAME : nom du cluster.

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

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

  1. Dans la Google Cloud console, 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 inclut 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 la 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 correspond au numéro du projet appartenant à Google Cloudqui héberge les VM du plan de contrôle et IMAGE_NAME au 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 vérifier la VSA pour les images de VM du plan de contrôle

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

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

Le fichier correspondant à votre VM du 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 la 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 la VM, qui correspond à la valeur du champ attachedDisks.sourceImageId du journal d'audit de la VM de la section précédente. Par exemple, 9046093115864736653.

Pour rechercher et vérifier la VSA lorsque vous connaissez le nom de fichier de votre fichier VSA, procédez comme suit :

  1. Ouvrez le gke-vsa dépôt GitHub.
  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 pour vérifier la VSA dans un fichier nommé vsa_signing_public_key :

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

  6. Vérifiez la 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 la VM, par exemple gke-1302-gke1627000-cos-113-18244-85-49-c-pre.
    • IMAGE_ID: ID de l'image de la VM, par exemple 9046093115864736653.

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

    Verifying VSA: PASSED
PASSED: SLSA verification passed

Étape suivante