Integrität der VMs der GKE-Steuerungsebene prüfen

Sie können die Integrität des Compute Engine-Images für virtuelle Maschinen (VM) prüfen, das von Google Kubernetes Engine (GKE) für Steuerungsebenen-VMs verwendet wird. Diese Seite enthält eine Anleitung für ein Sicherheitsteam, das die Logs der Steuerungsebene überwacht, um Folgendes zu prüfen:

  • Die Steuerungsebenen-VM wurde mit authentischer Firmware und anderer Bootsoftware gestartet, die durch Secure Boot und Integritätsmonitoring kryptografisch verifiziert wurde.
  • Die Steuerungsebenen-VM wurde von einem authentischen GKE-Betriebssystem-Image gestartet.

Sie können diese Prüfung auch für die Betriebssystem-Images und die Bootintegrität Ihrer Knoten durchführen.

Auf dieser Seite wird ein Teil einer Reihe optionaler Funktionen der Steuerungsebene in GKE beschrieben, mit denen Sie Aufgaben wie das Prüfen des Sicherheitsstatus Ihrer Steuerungsebene oder das Konfigurieren der Verschlüsselung und der Signierung von Anmeldedaten in der Steuerungsebene mit von Ihnen verwalteten Schlüsseln ausführen können. Weitere Informationen finden Sie unter Informationen zur GKE-Steuerungsebene-Autorität.

Standardmäßig Google Cloud wendet verschiedene Sicherheitsmaßnahmen auf die verwaltete Steuerungsebene an. Auf dieser Seite werden optionale Funktionen beschrieben, die Ihnen mehr Einblick in die GKE-Steuerungsebene geben oder Ihnen mehr Kontrolle darüber ermöglichen.

VM-Integritätsprüfung

Standardmäßig sind alle GKE-Steuerungsebenen-Instanzen Shielded VMs. Das sind gehärtete VMs, die Sicherheitsfunktionen wie Secure Boot und Measured Boot, ein virtuelles Trusted Platform Module (vTPM) und UEFI-Firmware verwenden. Auf allen GKE-Knoten ist auch aktiviert, Integritätsmonitoring, das die Bootsequenz jeder Shielded VM mit einer Baseline-Bootsequenz vergleicht. Diese Prüfung gibt für jede Phase der Bootsequenz ein Ergebnis zurück und fügt diese Ergebnisse Cloud Logging hinzu. Das Integritätsmonitoring ist in allen GKE-Clustern standardmäßig aktiviert und prüft die folgenden Phasen:

  • Frühe Bootsequenz: vom Start der UEFI-Firmware bis zur Übernahme der Steuerung durch den Bootloader. Wird den VM-Logs als earlyBootReportEvent hinzugefügt.
  • Späte Startphase: von der Übernahme der Steuerung durch den Bootloader bis zur Übernahme der Steuerung durch den Betriebssystem-Kernel. Wird den VM-Logs als lateBootReportEvent hinzugefügt.

GKE fügt auch Logs zur Erstellung von Steuerungsebenen-VMs zu Logging hinzu. Diese Logs enthalten Metadaten, die die Maschine identifizieren und Details zum VM-Image und zur Bootsequenz enthalten. Google Cloud veröffentlicht eine Zusammenfassung der Verifizierung (Verification Summary Attestation, VSA) für jedes GKE-Steuerungsebenen-VM-Image im gke-vsa-Repository auf GitHub. Die VSA verwendet das in-toto-Framework für Attestierungen. Sie können die Logs der Steuerungsebenen-VM für Ihre Cluster mit den entsprechenden VSAs vergleichen, um zu prüfen, ob die Knoten der Steuerungsebene wie erwartet gestartet wurden.

Durch diese Prüfungen können Sie Folgendes erreichen:

  • Sicherstellen, dass die Software auf der Steuerungsebene durch Secure Boot und Integritätsmonitoring geschützt ist, mit dem beabsichtigten Quellcode übereinstimmt und genau dem Image entspricht, das andere Google Cloud Kunden verwenden.
  • Mehr Vertrauen in die Art und Weise gewinnen, wie GKE die Steuerungsebene schützt.

Preise

Diese Funktion wird in GKE ohne zusätzliche Kosten angeboten.

Hinweis

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
    • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diesen Task verwenden möchten, installieren und dann initialisieren Sie die gcloud CLI. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem gcloud components update Befehl ab. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.

  • Cloud Logging API aktivieren

    Erforderliche Rollen zum Aktivieren von APIs

    Zum Aktivieren von APIs benötigen Sie die IAM-Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin), die die Berechtigung serviceusage.services.enable enthält. Informationen zum Zuweisen von Rollen.

    API aktivieren

  • Achten Sie darauf, dass Sie bereits einen GKE Autopilot- oder Standardcluster mit Version 1.29 oder höher haben.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für Ihr Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Prüfen der Integrität der Steuerungsebenen-VM benötigen:

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

Auf fehlgeschlagene Phasen der Bootsequenz prüfen

Das Integritätsmonitoring fügt Logging einen Log hinzu, wenn eine Steuerungsebenen-VM eine Phase der Bootsequenz nicht abschließt oder erfolgreich abschließt. Führen Sie die folgenden Befehle aus, um fehlgeschlagene Bootereignisse aufzurufen:

  1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf:

    Zum Log-Explorer

  2. Geben Sie im Feld Abfrage die folgende Abfrage ein:

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

    Sie können auch nach erfolgreichen Bootereignissen suchen, indem Sie false in dieser Abfrage durch true ersetzen.

  3. Klicken Sie auf Abfrage ausführen. Wenn keine Ergebnisse angezeigt werden, haben Ihre Steuerungsebenen-VMs alle Prüfungen des Integritätsmonitorings bestanden. Wenn eine Ausgabe angezeigt wird, fahren Sie mit dem nächsten Schritt fort, um den entsprechenden Cluster zu identifizieren.

  4. Kopieren Sie im Log für die fehlgeschlagene Bootintegrität den Wert im Feld resource.labels.instance_id.

  5. Geben Sie im Feld Abfrage die folgende Abfrage ein:

    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"

    Ersetzen Sie INSTANCE_ID durch den Wert des Feldes instance_id aus dem vorherigen Schritt.

  6. Klicken Sie auf Abfrage ausführen. Der Wert im Feld protoPayload.metadata.parentResource.parentResourceId ist die GKE-Cluster-ID.

  7. Suchen Sie den Namen des GKE-Cluster:

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

    Ersetzen Sie Folgendes:

    • ORGANIZATION_ID: die numerische ID Ihrer Google Cloud Organisation.
    • CLUSTER_ID: der Wert des Feldes protoPayload.metadata.parentResource.parentResourceId aus dem vorherigen Schritt.

    Die Ausgabe sieht etwa so aus:

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

    Diese Ausgabe enthält die folgenden Felder:

    • PROJECT_ID: Ihre Google Cloud Projekt-ID.
    • LOCATION: Der Standort des Clusters.
    • CLUSTER_NAME: Der Name des Clusters.

Logs der Steuerungsebenen-VM suchen und prüfen

Die Logs zur Erstellung von Compute Engine-VMs, die GKE-Clustern entsprechen, werden im _Default Log-Bucket gespeichert. So suchen Sie die Erstellungslogs für die VMs der Steuerungsebene Ihres Clusters und rufen diese Metadaten ab:

  1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf:

    Zum Log-Explorer

  2. Geben Sie im Feld Abfrage die folgende Abfrage ein:

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

  3. Klicken Sie auf Abfrage ausführen. Wenn keine Ergebnisse angezeigt werden, prüfen Sie, ob Sie alle Anforderungen im Abschnitt Hinweis erfüllen.

  4. Prüfen Sie in den Abfrageergebnissen das Feld metadata. Die Ausgabe sieht etwa so aus:

    # 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

    Das Feld metadata enthält die folgenden Informationen:

    • usedResources: die Liste der Ressourcen, die zum Erstellen der VM verwendet wurden.
    • attachedDisks: das Bootlaufwerk für die VM.
    • sourceImageId: die eindeutige ID des VM-Image.
    • sourceImage: die URL des Quell-VM-Image. Die Syntax des Werts in diesem Feld ist https://www.googleapis.com/compute/v1/projects/PROJECT_NUMBER/global/images/IMAGE_NAME, wobei PROJECT_NUMBER die Nummer des Google Cloud-eigenen Projekts ist, das die Steuerungsebenen-VMs hostet, und IMAGE_NAME der Name des Image ist, das zum Starten der VM verwendet wurde.
    • isBootDisk: ein boolescher Wert, der angibt, ob dieses Laufwerk als Bootlaufwerk für die VM verwendet wurde.

VSA für Steuerungsebenen-VM-Images suchen und prüfen

In diesem Abschnitt suchen Sie die VSA, die Ihrem Steuerungsebenen-VM-Image entspricht, im gke-vsa-Repository auf GitHub. Anschließend prüfen Sie die VSA mit dem Tool slsa-verifier, das vom SLSA-Framework (Supply Chain Levels for Software Artifacts) bereitgestellt wird. Sie benötigen die folgenden Daten aus dem Log zur Erstellung der Steuerungsebenen-VM:

  • Die VM-Image-ID
  • Die Projektnummer des Google CloudProjekts, das die VMs hostet
  • Der Name des Betriebssystem-Image, das zum Starten der VM verwendet wurde

Die Datei, die Ihrer Steuerungsebenen-VM entspricht, hat das folgende Dateinamenformat:

IMAGE_NAME:IMAGE_ID.intoto.jsonl

Ersetzen Sie Folgendes:

  • IMAGE_NAME: der Name des VM-Image, der String nach /images/ im Feld attachedDisks.sourceImage im VM-Audit-Log aus dem vorherigen Abschnitt. Beispiel: gke-1302-gke1627000-cos-113-18244-85-49-c-pre.
  • IMAGE_ID: die VM-Image-ID, der Wert des Feldes attachedDisks.sourceImageId im VM-Audit-Log aus dem vorherigen Abschnitt. Beispiel: 9046093115864736653.

So suchen und prüfen Sie die VSA, wenn Sie den Dateinamen Ihrer VSA-Datei kennen:

  1. Öffnen Sie das gke-vsa GitHub-Repository.
  2. Suchen Sie im Verzeichnis „gke-master-images“ die Datei, die Ihrem VM-Image entspricht. Beispiel: https://github.com/GoogleCloudPlatform/gke-vsa/blob/main/gke-master-images:78064567238/IMAGE_NAME:IMAGE_ID.intoto.jsonl
  3. Laden Sie die VSA-Datei herunter.
  4. Installieren Sie das Tool slsa-verifier.

  5. Speichern Sie den öffentlichen Schlüssel zum Prüfen der VSA in einer Datei mit dem Namen vsa_signing_public_key:

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

  6. Prüfen Sie die 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

    Ersetzen Sie Folgendes:

    • PATH_TO_VSA_FILE: der Pfad zur heruntergeladenen VSA-Datei.
    • IMAGE_NAME: der Name des VM-Image, z. B. gke-1302-gke1627000-cos-113-18244-85-49-c-pre.
    • IMAGE_ID: die VM-Image-ID, z. B. 9046093115864736653.

    Wenn die VSA die Prüfungen besteht, sieht die Ausgabe so aus:

    Verifying VSA: PASSED
PASSED: SLSA verification passed

Nächste Schritte