Verifica l'integrità della VM del control plane GKE

Questa guida descrive come verificare l'integrità dell'immagine della macchina virtuale (VM) Compute Engine utilizzata da Google Kubernetes Engine (GKE) per le VM del control plane. Questa guida è destinata a un team di sicurezza che monitora i log del control plane e vuole verificare quanto segue:

  • La VM del control plane è stata avviata con firmware autentico e altro software di avvio verificato crittograficamente tramite l'avvio protetto e il monitoraggio dell'integrità.
  • La VM del control plane è stata avviata da un'immagine GKE OS autentica.

Puoi anche eseguire questa verifica per le immagini del sistema operativo e l'integrità di avvio dei nodi worker.

Questa pagina descrive una parte di un insieme di funzionalità opzionali del control plane in GKE che ti consente di eseguire attività come la verifica del livello di sicurezza del control plane o la configurazione della crittografia e della firma delle credenziali nel control plane utilizzando chiavi che gestisci. Per maggiori dettagli, consulta l'articolo Informazioni sull'autorità del piano di controllo GKE.

Per impostazione predefinita, Trusted Cloud applica varie misure di sicurezza al piano di controllo gestito. Questa pagina descrive le funzionalità facoltative che offrono maggiore visibilità o controllo sul piano di controllo GKE.

Informazioni sulla verifica dell'integrità della VM

Per impostazione predefinita, tutte le istanze del control plane GKE sono Shielded VM, ovvero VM protette che utilizzano funzionalità di sicurezza come l'avvio protetto e con misurazioni, un Trusted Platform Module virtuale (vTPM) e il firmware UEFI. Tutti i nodi GKE abilitano anche il monitoraggio dell'integrità, che convalida la sequenza di avvio di ogni Shielded VM rispetto a una sequenza di avvio "buona" di base. Questa convalida restituisce risultati positivi o negativi per ogni fase della sequenza di avvio e aggiunge questi risultati a Cloud Logging. Il monitoraggio dell'integrità è abilitato per impostazione predefinita in tutti i cluster GKE e convalida le seguenti fasi:

  • Sequenza di avvio iniziale: da quando inizia il firmware UEFI fino a quando il bootloader prende il controllo. Aggiunto ai log della VM come earlyBootReportEvent.
  • Sequenza di avvio finale: da quando il bootloader prende il controllo fino a quando il kernel del sistema operativo prende il controllo. Aggiunto ai log della VM come lateBootReportEvent.

GKE aggiunge anche i log di creazione delle VM del control plane a Logging. Questi log contengono metadati che identificano la macchina e includono dettagli sull'immagine VM e sulla sequenza di avvio.Trusted Cloud pubblica un'attestazione di riepilogo della verifica (VSA) per ogni immagine VM del control plane GKE nel repository gke-vsa su GitHub. Il VSA utilizza il framework in toto per le attestazioni. Puoi convalidare i log delle VM del control plane per i tuoi cluster rispetto alle VSA corrispondenti per verificare che i nodi del control plane siano stati avviati come previsto.

L'esecuzione di queste convalide può aiutarti a raggiungere i seguenti obiettivi:

  • Assicurati che il software sul control plane sia protetto dall'avvio protetto e dal monitoraggio dell'integrità, corrisponda al codice sorgente previsto e sia esattamente lo stesso dell'immagine utilizzata da altri Trusted Cloud clienti.
  • Aumenta la tua fiducia nel modo in cui GKE protegge il control plane.

Prezzi

Questa funzionalità è offerta senza costi aggiuntivi in GKE.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

  • Attiva l'API Google Kubernetes Engine.
    • Attiva l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.

  • Enable the Cloud Logging API.

    Enable the API

  • Assicurati di avere già un cluster in modalità GKE Autopilot o in modalità Standard che esegue la versione 1.29 o successive.

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per verificare l'integrità della VM del control plane, chiedi all'amministratore di concederti i seguenti ruoli IAM nel progetto:

Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

Controllare le fasi della sequenza di avvio non riuscite

Il monitoraggio dell'integrità aggiunge un log a Logging se una VM del control plane non riesce a completare una fase della sequenza di avvio o la completa correttamente. Per visualizzare gli eventi di avvio non riusciti, esegui questi comandi:

  1. Nella Trusted Cloud console, vai alla pagina Esplora log:

    Vai a Esplora log

  2. Nel campo Query, specifica la seguente query:

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

    Puoi anche verificare la presenza di eventi di avvio riusciti sostituendo false con true in questa query.

  3. Fai clic su Esegui query. Se non vedi risultati, significa che le VM del control plane hanno superato tutti i controlli di monitoraggio dell'integrità. Se visualizzi un output, vai al passaggio successivo per identificare il cluster corrispondente.

  4. Nel log di integrità dell'avvio non riuscito, copia il valore nel campo resource.labels.instance_id.

  5. Nel campo Query, specifica la seguente query:

    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"

    Sostituisci INSTANCE_ID con il valore del campo instance_id del passaggio precedente.

  6. Fai clic su Esegui query. Il valore nel campo protoPayload.metadata.parentResource.parentResourceId è l'ID del cluster GKE.

  7. Trova il nome del cluster GKE:

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

    Sostituisci quanto segue:

    • ORGANIZATION_ID: l'ID numerico della tua organizzazioneTrusted Cloud .
    • CLUSTER_ID: il valore del campo protoPayload.metadata.parentResource.parentResourceId del passaggio precedente.

    L'output è simile al seguente:

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

    Questo output include i seguenti campi:

    • PROJECT_ID: il tuo ID progetto Trusted Cloud .
    • LOCATION: la posizione del cluster.
    • CLUSTER_NAME: il nome del cluster.

Trovare e ispezionare i log della VM del control plane

I log di creazione delle VM Compute Engine corrispondenti ai cluster GKE vengono archiviati nel bucket di log _Default. Per trovare i log di creazione delle VM del piano di controllo del cluster e recuperare questi metadati, procedi nel seguente modo:

  1. Nella Trusted Cloud console, vai alla pagina Esplora log:

    Vai a Esplora log

  2. Nel campo Query, specifica la seguente query:

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

  3. Fai clic su Esegui query. Se non vedi risultati, verifica di soddisfare tutti i requisiti della sezione Prima di iniziare.

  4. Nei risultati della query, controlla il campo metadata. L'output è simile al seguente:

    # 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

    Il campo metadata include le seguenti informazioni:

    • usedResources: l'elenco delle risorse utilizzate per creare la VM.
    • attachedDisks: il disco di avvio della VM.
    • sourceImageId: l'ID univoco dell'immagine VM.
    • sourceImage: l'URL dell'immagine VM di origine. La sintassi del valore in questo campo è https://www.googleapis.com/compute/v1/projects/PROJECT_NUMBER/global/images/IMAGE_NAME, dove PROJECT_NUMBER è il numero del progetto di proprietà diTrusted Cloudche ospita le VM del control plane e IMAGE_NAME è il nome dell'immagine utilizzata per avviare la VM.
    • isBootDisk: un identificatore booleano che indica se questo disco è stato utilizzato come disco di avvio per la VM.

Trovare e verificare la VSA per le immagini VM del control plane

In questa sezione trovi il VSA corrispondente all'immagine VM del piano di controllo nel repository gke-vsa su GitHub. Successivamente, utilizzi uno strumento denominato slsa-verifier fornito dal framework Supply chain Levels for Software Artifacts (SLSA) per verificare la VSA. Sono necessari i seguenti dati dal log di creazione della VM del control plane:

  • L'ID immagine VM
  • Il numero di progetto del progetto di proprietà di Trusted Cloudche ospita le VM
  • Il nome dell'immagine del sistema operativo utilizzata per avviare la VM

Il file corrispondente alla VM del piano di controllo ha il seguente formato del nome file:

IMAGE_NAME:IMAGE_ID.intoto.jsonl

Sostituisci quanto segue:

  • IMAGE_NAME: il nome dell'immagine VM, ovvero la stringa dopo /images/ nel campo attachedDisks.sourceImage nel log di controllo VM della sezione precedente. Ad esempio gke-1302-gke1627000-cos-113-18244-85-49-c-pre.
  • IMAGE_ID: l'ID immagine VM, ovvero il valore del campo attachedDisks.sourceImageId nel log di controllo VM della sezione precedente. Ad esempio 9046093115864736653.

Per trovare e verificare il VSA quando conosci il nome del file VSA, segui questa procedura:

  1. Apri il repository GitHub gke-vsa.
  2. Nella directory "gke-master-images", individua il file corrispondente all'immagine VM. Ad esempio, https://github.com/GoogleCloudPlatform/gke-vsa/blob/main/gke-master-images:78064567238/IMAGE_NAME:IMAGE_ID.intoto.jsonl
  3. Scarica il file VSA.
  4. Installa lo strumento slsa-verifier.

  5. Salva la chiave pubblica per la verifica della VSA in un file denominato vsa_signing_public_key:

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

  6. Verifica 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

    Sostituisci quanto segue:

    • PATH_TO_VSA_FILE: il percorso del file VSA che hai scaricato.
    • IMAGE_NAME: il nome dell'immagine VM, ad esempio gke-1302-gke1627000-cos-113-18244-85-49-c-pre.
    • IMAGE_ID: l'ID immagine VM, ad esempio 9046093115864736653.

    Se il VSA supera i controlli di verifica, l'output è il seguente:

    Verifying VSA: PASSED
PASSED: SLSA verification passed

Passaggi successivi