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

In diesem Leitfaden wird beschrieben, wie Sie die Integrität des Compute Engine-VM-Images prüfen, das von der Google Kubernetes Engine (GKE) für VMs der Kontrollebene verwendet wird. Dieser Leitfaden richtet sich an ein Sicherheitsteam, das die Protokolle des Kontrollplans überwacht und Folgendes prüfen möchte:

  • Die VM der Kontrollebene wurde mit authentischer Firmware und anderer Boot-Software gestartet, die durch Secure Boot und Integritätsüberwachung kryptografisch verifiziert wurde.
  • Die VM der Steuerungsebene wurde von einem authentischen GKE-Betriebssystem-Image gestartet.

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

Auf dieser Seite wird ein Teil der optionalen Funktionen der Steuerungsebene in GKE beschrieben, mit denen Sie Aufgaben wie die Überprüfung des Sicherheitsstatus der Steuerungsebene oder die Konfiguration der Verschlüsselung und Anmeldedatensignatur in der Steuerungsebene mit von Ihnen verwalteten Schlüsseln ausführen können. Weitere Informationen finden Sie unter GKE Control Plane Authority.

Standardmäßig werden in Google Cloud verschiedene Sicherheitsmaßnahmen auf die verwaltete Steuerebene angewendet. Auf dieser Seite werden optionale Funktionen beschrieben, mit denen Sie die GKE-Steuerungsebene besser im Blick behalten oder steuern können.

VM-Integritätsprüfung

Standardmäßig sind alle GKE-Steuerungsebeneninstanzen Shielded VMs, also gehärtete VMs, die Sicherheitsfunktionen wie Secure Boot und Measured Boot, ein vTPM (Virtual Trusted Platform Module) und UEFI-Firmware verwenden. Auf allen GKE-Knoten ist außerdem das Integritätsmonitoring aktiviert, bei dem die Bootreihenfolge jeder Shielded VM anhand einer fehlerfreien Baseline-Bootreihenfolge überprüft wird. Diese Validierung gibt für jede Phase der Bootreihenfolge Ergebnisse vom Typ „Erfolg“ oder „Fehlgeschlagen“ zurück und fügt diese Ergebnisse Cloud Logging hinzu. Die Integritätsüberwachung ist in allen GKE-Clustern standardmäßig aktiviert und validiert die folgenden Phasen:

  • Frühe Startsequenz: Vom Start der UEFI-Firmware bis zur Übernahme der Kontrolle durch den Bootloader. Wird den VM-Protokollen als earlyBootReportEvent hinzugefügt.
  • Späte Startsequenz: Vom Zeitpunkt, an dem der Bootloader die Kontrolle übernimmt, bis zum Zeitpunkt, an dem der Betriebssystem-Kernel die Kontrolle übernimmt. Wird den VM-Protokollen als lateBootReportEvent hinzugefügt.

GKE fügt Logging auch Protokolle zur Erstellung von VMs der Steuerungsebene hinzu. Diese Protokolle enthalten Metadaten, die den Computer identifizieren, sowie Details zum VM-Image und zur Bootreihenfolge. Google Cloud veröffentlicht für jedes GKE-VM-Image der Steuerungsebene eine Bestätigungszusammenfassung (Verification Summary Attestation, VSA) im gke-vsa-Repository auf GitHub. Die VSA verwendet das In-Toto-Framework für Attestationen. Sie können die VM-Logs der Steuerungsebene 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 die folgenden Ziele erreichen:

  • Die Software auf der Kontrollebene muss durch Secure Boot und Integritätsprüfung geschützt sein, mit dem vorgesehenen Quellcode übereinstimmen und genau mit dem Image identisch sein, das andere Google Cloud -Kunden verwenden.
  • Sie können sich darauf verlassen, dass die GKE die Steuerungsebene sichert.

Preise

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

Hinweise

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 diese Aufgabe verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit gcloud components update ab.

  • Enable the Cloud Logging API.

    Enable the API

  • Sie benötigen einen GKE-Cluster im Autopilot- oder Standardmodus mit Version 1.29 oder höher.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für Ihr Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Überprüfen der VM-Integrität der Kontrollebene 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.

Prüfen, ob Phasen der Bootreihenfolge fehlgeschlagen sind

Beim Integritätsmonitoring wird dem Logging-Verzeichnis ein Log hinzugefügt, wenn eine VM der Steuerungsebene fehlschlägt oder eine Phase der Bootreihenfolge erfolgreich abgeschlossen wird. Führen Sie die folgenden Befehle aus, um fehlgeschlagene Startereignisse aufzurufen:

  1. Rufen Sie in der Google Cloud -Konsole 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 Boot-Ereignissen suchen, indem Sie in dieser Abfrage false durch true ersetzen.

  3. Klicken Sie auf Abfrage ausführen. Wenn keine Ergebnisse angezeigt werden, haben die VMs der Steuerungsebene alle Integritätsüberwachungs-Prüfungen bestanden. Wenn eine Ausgabe angezeigt wird, fahren Sie mit dem nächsten Schritt fort, um den entsprechenden Cluster zu ermitteln.

  4. Kopieren Sie im Protokoll zur fehlgeschlagenen 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 Felds 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 IhrerGoogle Cloud -Organisation.
    • CLUSTER_ID: Der Wert des Felds protoPayload.metadata.parentResource.parentResourceId aus dem vorherigen Schritt.

    Die Ausgabe sieht in 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: Die Projekt-ID Ihrer Google Cloud .
    • LOCATION: Der Standort des Clusters.
    • CLUSTER_NAME ist der Name des Clusters.

VM-Logs der Steuerungsebene finden und prüfen

Die Logs zur Erstellung von Compute Engine-VMs, die GKE-Clustern entsprechen, werden im _Default-Log-Bucket gespeichert. So rufen Sie die Erstellungsprotokolle für Ihre VMs der Clustersteuerungsebene auf und rufen Sie diese Metadaten ab:

  1. Rufen Sie in der Google Cloud -Konsole 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 Voraussetzungen im Abschnitt Vorbereitung erfüllen.

  4. Prüfen Sie in den Abfrageergebnissen das Feld metadata. Die Ausgabe sieht in 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: Liste der Ressourcen, die zum Erstellen der VM verwendet wurden.
    • attachedDisks: Das Bootlaufwerk der VM.
    • sourceImageId: die eindeutige ID des VM-Images.
    • sourceImage: die URL des Quell-VM-Images. Die Syntax des Werts in diesem Feld lautet https://www.googleapis.com/compute/v1/projects/PROJECT_NUMBER/global/images/IMAGE_NAME, wobei PROJECT_NUMBER die Nummer desGoogle Cloud-eigenen Projekts ist, in dem die VMs der Kontrollebene gehostet werden, und IMAGE_NAME der Name des Images ist, das zum Starten der VM verwendet wurde.
    • isBootDisk: Gibt an, ob dieses Laufwerk als Bootlaufwerk für die VM verwendet wurde.

VSA für VM-Images der Steuerungsebene finden und überprüfen

In diesem Abschnitt finden Sie die VSA, die dem VM-Image Ihrer Steuerungsebene im gke-vsa-Repository auf GitHub entspricht. Anschließend verwenden Sie das Tool slsa-verifier aus dem Framework „Supply Chain Levels for Software Artifacts“ (SLSA), um die VSA zu überprüfen. Sie benötigen die folgenden Daten aus dem Log zur VM-Erstellung der Steuerungsebene:

  • Die VM-Image-ID
  • Die Projektnummer des Google Cloud-eigenen Projekts, in dem die VMs gehostet werden
  • Der Name des Betriebssystem-Images, mit dem die VM gestartet wurde

Die Datei, die Ihrer VM der Steuerungsebene entspricht, hat das folgende Dateinamenformat:

IMAGE_NAME:IMAGE_ID.intoto.jsonl

Ersetzen Sie Folgendes:

  • IMAGE_NAME: Der Name des VM-Images. Das ist 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, also der Wert des Felds attachedDisks.sourceImageId im VM-Audit-Log aus dem vorherigen Abschnitt. Beispiel: 9046093115864736653.

Wenn Sie den Dateinamen Ihrer VSA-Datei kennen, gehen Sie so vor, um die VSA zu finden und zu bestätigen:

  1. Öffnen Sie das gke-vsa GitHub-Repository.
  2. Suchen Sie im Verzeichnis „gke-master-images“ nach der 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 slsa-verifier-Tool.

  5. Speichern Sie den öffentlichen Schlüssel zur Bestätigung 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: Pfad zur heruntergeladenen VSA-Datei
    • IMAGE_NAME: der Name des VM-Images, 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 Überprüfungen besteht, sieht die Ausgabe so aus:

    Verifying VSA: PASSED
PASSED: SLSA verification passed

Nächste Schritte