Verifica l'integrità della VM del control plane GKE

Puoi verificare l'integrità dell'immagine della macchina virtuale (VM) Compute Engine utilizzata da Google Kubernetes Engine (GKE) per le VM del piano di controllo. Questa pagina fornisce istruzioni per un team di sicurezza che monitora i log del piano di controllo per verificare quanto segue:

  • La VM del piano di controllo è stata avviata con firmware autentico e altro software di avvio verificato crittograficamente dall'avvio protetto e dal monitoraggio dell'integrità.
  • La VM del piano di controllo è stata avviata da un'immagine del sistema operativo GKE autentica.

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

Questa pagina descrive una parte di un insieme di funzionalità del piano di controllo facoltative in GKE che ti consentono di eseguire attività come la verifica della security posture del piano di controllo o la configurazione della crittografia e della firma delle credenziali nel piano di controllo utilizzando le chiavi che gestisci. Per i dettagli, consulta Informazioni sull'autorità del piano di controllo GKE.

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

Informazioni sulla verifica dell'integrità della VM

Per impostazione predefinita, tutte le istanze del piano di controllo GKE sono Shielded VM, ovvero VM rafforzate 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 di superamento o errore per ogni fase della sequenza di avvio e li aggiunge 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 il firmware UEFI si avvia fino a quando il bootloader non prende il controllo. Aggiunta 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 non prende il controllo. Aggiunta ai log della VM come lateBootReportEvent.

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

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

  • Assicurati che il software sul piano di controllo sia protetto dall'avvio protetto e dal monitoraggio dell'integrità, che corrisponda al codice sorgente previsto e che sia esattamente uguale all'immagine utilizzata da altri Cloud de Confiance clienti.
  • Migliora la tua fiducia nel modo in cui GKE protegge il piano di controllo.

Prezzi

Questa funzionalità è offerta senza costi aggiuntivi in GKE.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

  • Abilita l'API Google Kubernetes Engine.
  • Abilita l'API Google Kubernetes Engine
  • Per utilizzare Google Cloud CLI per questa attività, installa e poi inizializza la gcloud CLI. Se hai installato in precedenza gcloud CLI, scarica l'ultima versione eseguendo il gcloud components update comando. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
  • Abilita l'API Cloud Logging.

    Ruoli richiesti per abilitare le API

    Per abilitare le API, devi disporre del ruolo IAM Amministratore utilizzo servizi (roles/serviceusage.serviceUsageAdmin), che contiene l'autorizzazione serviceusage.services.enable. Scopri come concedere i ruoli.

    Abilitare l'API

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

Ruoli obbligatori

Per ottenere le autorizzazioni necessarie per verificare l'integrità della VM del piano di controllo, 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 essere in grado di ottenere le autorizzazioni richieste tramite ruoli personalizzati o altri ruoli predefiniti.

Verifica la presenza di fasi della sequenza di avvio non riuscite

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

  1. Nella Cloud de Confiance 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, le VM del piano di controllo hanno superato tutti i controlli di monitoraggio dell'integrità. Se vedi un output, procedi 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 Cloud de Confiance organizzazione.
    • 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: l'ID del tuo Cloud de Confiance progetto.
    • LOCATION: la località del cluster.
    • CLUSTER_NAME: il nome del cluster.

Trova e ispeziona i log delle VM del piano di controllo

I log di creazione delle VM Compute Engine che corrispondono ai cluster GKE sono archiviati nel _Default bucket di log. Per trovare i log di creazione delle VM del piano di controllo del cluster e recuperare questi metadati:

  1. Nella Cloud de Confiance 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 nella Prima di iniziare sezione.

  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 della VM.
    • sourceImage: l'URL dell'immagine della 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à di Cloud de Confianceche ospita le VM del piano di controllo 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.

Trova e verifica la VSA per le immagini delle VM del piano di controllo

In questa sezione, troverai la VSA che corrisponde all'immagine della VM del piano di controllo nel repository gke-vsa su GitHub. Poi utilizzerai 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 piano di controllo:

  • L'ID dell'immagine della VM
  • Il numero di progetto del progetto di proprietà di Cloud de Confianceche ospita le VM
  • Il nome dell'immagine del sistema operativo utilizzata per avviare la VM

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

IMAGE_NAME:IMAGE_ID.intoto.jsonl

Sostituisci quanto segue:

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

Per trovare e verificare la VSA quando conosci il nome del file VSA, segui questi passaggi:

  1. Apri il gke-vsa repository GitHub.
  2. Nella directory "gke-master-images", trova il file che corrisponde all'immagine della 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 della VM, ad esempio gke-1302-gke1627000-cos-113-18244-85-49-c-pre.
    • IMAGE_ID: l'ID dell'immagine della VM, ad esempio 9046093115864736653.

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

    Verifying VSA: PASSED
    PASSED: SLSA verification passed
    

Passaggi successivi