Cette page a été traduite par l'API Cloud Translation.

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 utilisée par Google Kubernetes Engine (GKE) pour les VM de plan de contrôle. Ce guide s'adresse à 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 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 de l'OS et l'intégrité du démarrage de vos nœuds de calcul.

Cette page décrit une partie d'un ensemble de fonctionnalités facultatives du plan de contrôle dans GKE qui 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 la section À 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 une meilleure visibilité ou un meilleur 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 sécurisé et mesuré, un module vTPM (Virtual Trusted Platform Module) et un 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 lancement du micrologiciel UEFI jusqu'à la prise de contrôle par le bootloader. Ajouté aux journaux de la VM en tant que earlyBootReportEvent.
Séquence de démarrage tardive: du moment où le bootloader prend le contrôle jusqu'au moment où le noyau du système d'exploitation prend le contrôle. Ajouté aux journaux de la VM en tant que lateBootReportEvent.

GKE ajoute également des journaux de création de VM de 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 vérification (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 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.

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 Google Cloud .
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 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.
Remarque : Pour les installations de gcloud CLI existantes, veillez à définir les propriétés compute/region et compute/zone. En définissant des emplacements par défaut, vous pouvez éviter les erreurs gcloud CLI telles que celle-ci : One of [--zone, --region] must be supplied: Please specify location.

Enable the Cloud Logging API.
Enable the API
Assurez-vous de disposer déjà 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é des VM du plan de contrôle, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre projet:

Créer et interagir avec des clusters : Administrateur de cluster Kubernetes Engine (roles/container.clusterAdmin)
Journaux d'accès et de traitement : Lecteur de journaux (roles/logging.viewer)

Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises via 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 avec succès une phase de la séquence de démarrage. Pour afficher les événements de démarrage ayant échoué, exécutez les commandes suivantes:

Dans la console Google Cloud , accédez à la page Explorateur de journaux:

Accéder à l'explorateur de journaux

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.

Cliquez sur Exécuter la requête. Si aucun résultat ne s'affiche, cela signifie que vos VM de plan de contrôle ont réussi toutes les vérifications de surveillance de l'intégrité. Si une sortie s'affiche, passez à l'étape suivante pour identifier le cluster correspondant.
Dans le journal d'intégrité de démarrage ayant échoué, copiez la valeur du champ resource.labels.instance_id.

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.

Cliquez sur Exécuter la requête. La valeur du champ protoPayload.metadata.parentResource.parentResourceId correspond à l'ID du cluster GKE.
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 organisationGoogle 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 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 qui correspondent 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:

Dans la console Google Cloud , accédez à la page Explorateur de journaux:

Accéder à l'explorateur de journaux

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

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

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.
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 comprend 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 la 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 àGoogle Cloudqui héberge les VM de 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 de la VM.

Rechercher et vérifier la VSA pour les images de VM de plan de contrôle

Dans cette section, vous trouverez le VSA qui correspond à l'image de VM de votre 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 vérifier la VSA. Vous avez besoin des données suivantes du journal de création de la VM de plan de contrôle:

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

Le fichier qui correspond à votre VM de plan de contrôle a 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 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 le nom de fichier de votre fichier VSA, procédez comme suit:

Ouvrez le dépôt GitHub gke-vsa.
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.
Téléchargez le fichier VSA.
Installez l'outil slsa-verifier.

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

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

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 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 le VSA réussit les vérifications, le résultat est le suivant:

Verifying VSA: PASSED
PASSED: SLSA verification passed

Étape suivante

Découvrez les autres éléments que vous pouvez afficher dans le plan de contrôle.