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

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

  • Die VM der Steuerungsebene wurde mit authentischer Firmware und anderer Bootsoftware gestartet, die durch Secure Boot und Integritätsmonitoring kryptografisch überprüft 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 Boot-Integrität Ihrer Knoten durchführen.

Auf dieser Seite wird ein Teil einer Reihe optionaler Steuerungsebenenfunktionen in GKE beschrieben, mit denen Sie Aufgaben wie das Überprüfen des Sicherheitsstatus der Steuerungsebene oder das Konfigurieren der Verschlüsselung und der Anmeldedatensignierung 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 Steuerungsebene angewendet. Auf dieser Seite werden optionale Funktionen beschrieben, mit denen Sie mehr Einblick in die GKE-Steuerungsebene erhalten oder mehr Kontrolle darüber haben.

Informationen zur VM-Integritätsprüfung

Standardmäßig sind alle GKE-Steuerungsebeneninstanzen 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 das Integritätsmonitoring aktiviert, das die Bootsequenz jeder Shielded VM mit einer Baseline-Bootsequenz vergleicht. Bei dieser Validierung werden für jede Phase der Bootsequenz Ergebnisse (bestanden oder nicht bestanden) zurückgegeben und diese Ergebnisse werden in Cloud Logging hinzugefügt. Das Integritätsmonitoring ist in allen GKE-Clustern standardmäßig aktiviert und validiert die folgenden Phasen:

  • Früher Start: von dem Zeitpunkt an, zu dem die UEFI-Firmware startet, bis der Bootloader die Steuerung übernimmt. Den VM-Logs wurde earlyBootReportEvent hinzugefügt.
  • Späte Startsequenz: Ab dem Zeitpunkt, an dem der Bootloader die Kontrolle übernimmt, bis der Betriebssystemkernel die Kontrolle übernimmt. Den VM-Logs wurde als lateBootReportEvent hinzugefügt.

GKE fügt auch Logs zur Erstellung von VMs für die Steuerungsebene zu Logging hinzu. Diese Logs enthalten Metadaten, die die Maschine identifizieren, sowie Details zum VM-Image und zur Bootsequenz. Google Cloud veröffentlicht für jedes GKE-Steuerungsebenen-VM-Image im gke-vsa-Repository auf GitHub eine Verification Summary Attestation (VSA). Die VSA verwendet das In-Toto-Framework für Attestierungen. 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.

Mit diesen Validierungen können Sie die folgenden Ziele erreichen:

  • Achten Sie darauf, dass die Software auf der Steuerungsebene durch Secure Boot und Integritätsüberwachung geschützt ist, mit dem vorgesehenen Quellcode übereinstimmt und genau dem Image entspricht, das andere Google Cloud -Kunden verwenden.
  • Sie können sich besser darauf verlassen, wie GKE die Steuerungsebene schützt.

Preise

Diese Funktion wird in GKE ohne Aufpreis 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 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 dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.

  • Aktivieren Sie die Cloud Logging API, falls sie noch nicht aktiviert ist.

    Rollen, die zum Aktivieren von APIs erforderlich sind

    Zum Aktivieren von APIs benötigen Sie die Berechtigung serviceusage.services.enable. Wenn Sie das Projekt erstellt haben, haben Sie diese Berechtigung wahrscheinlich bereits über die Rolle „Inhaber“ (roles/owner). Andernfalls können Sie diese Berechtigung über die Rolle „Service Usage-Administrator“ (roles/serviceusage.serviceUsageAdmin) erhalten. Informationen zum Zuweisen von Rollen

    API aktivieren

  • 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 das Projekt zuzuweisen, damit Sie die nötigen Berechtigungen für die Überprüfung der Integrität der VM der Steuerungsebene haben:

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

Beim Integritätsmonitoring wird Logging ein Log hinzugefügt, wenn eine VM der Steuerungsebene fehlschlägt oder eine Phase der Bootsequenz erfolgreich abschließt. Führen Sie die folgenden Befehle aus, um fehlgeschlagene Boot-Vorgänge 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 Boot-Vorgängen 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ätsprüfungen bestanden. Wenn Sie eine Ausgabe sehen, fahren Sie mit dem nächsten Schritt fort, um den entsprechenden Cluster zu ermitteln.

  4. Kopieren Sie im fehlgeschlagenen Boot-Integritätslog 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 etwa so aus:

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

    Diese Ausgabe hat die folgenden Felder:

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

VM-Logs der Steuerungsebene suchen und prüfen

Die Compute Engine-VM-Erstellungslogs, die GKE-Clustern entsprechen, werden im Log-Bucket _Default gespeichert. So finden 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 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: Die Liste der Ressourcen, die zum Erstellen der VM verwendet wurden.
    • attachedDisks: Das Bootlaufwerk für die VM.
    • sourceImageId: die eindeutige ID des VM-Images.
    • sourceImage: Die URL des Quell-VM-Images. 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 Projekts ist, dasGoogle Cloudgehört und in dem die VMs der Steuerungsebene gehostet werden, und IMAGE_NAME der Name des Images ist, das zum Booten der VM verwendet wurde.
    • isBootDisk: Ein boolescher Wert, der angibt, ob dieses Laufwerk als Bootlaufwerk für die VM verwendet wurde.

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

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

  • Die VM-Image-ID
  • Die Projektnummer des Projekts, das zu Google Cloudgehört und die VMs hostet.
  • Der Name des Betriebssystem-Images, das zum Booten der VM verwendet wurde

Die Datei, die Ihrer VM für die Steuerungsebene entspricht, hat das folgende Dateinamenformat:

IMAGE_NAME:IMAGE_ID.intoto.jsonl

Ersetzen Sie Folgendes:

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

Wenn Sie den Dateinamen Ihrer VSA-Datei kennen, führen Sie die folgenden Schritte aus, um die VSA zu finden und zu prüfen:

  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 zum Überprü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. VSA prüfen:

    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-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