Einige oder alle Informationen auf dieser Seite gelten möglicherweise nicht für Cloud de Confiance von S3NS. Weitere Informationen finden Sie unter Unterschiede zu Google Cloud.

Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

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

Autopilot Standard

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 überprü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 mit 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 Cloud de Confiance 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.

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 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 zurückgegeben, die angeben, ob die Phase bestanden oder fehlgeschlagen ist. Diese Ergebnisse werden in Cloud Logging hinzugefügt. Die Integritätsüberwachung ist standardmäßig in allen GKE-Clustern 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 Bootsequenz: vom Zeitpunkt, an dem der Bootloader die Steuerung übernimmt, bis zu dem Zeitpunkt, an dem der Betriebssystemkernel die Steuerung übernimmt. Wird den VM-Logs 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 den Computer identifizieren, sowie Details zum VM-Image und zur Bootsequenz. Cloud de Confiance veröffentlicht eine Zusammenfassung der Attestierung zur Überprüfung (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 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 beabsichtigten Quellcode übereinstimmt und genau dem Image entspricht, das andere Cloud de Confiance Kunden verwenden.
Sie können sich besser darauf verlassen, 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 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.
Hinweis: Legen Sie für vorhandene Installationen der gcloud CLI das compute/region-Attribut fest. Wenn Sie hauptsächlich zonale Cluster verwenden, legen Sie stattdessen compute/zone fest. Wenn Sie einen standardmäßigen Speicherort festlegen, können Sie in der gcloud CLI Fehler wie diesen vermeiden: One of [--zone, --region] must be supplied: Please specify location. Bei bestimmten Befehlen müssen Sie möglicherweise den Speicherort angeben, wenn er sich von dem von Ihnen festgelegten Standard unterscheidet.

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
Achten Sie darauf, dass Sie bereits einen GKE-Cluster im Autopilot- oder Standardmodus mit Version 1.29 oder höher haben.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für das Projekt zuzuweisen, damit Sie die nötigen Berechtigungen zum Prüfen der Integrität der Steuerungsebene-VM haben:

Cluster erstellen und mit ihnen interagieren: Administrator für Kubernetes Engine-Cluster (roles/container.clusterAdmin)
Auf Logs zugreifen und sie verarbeiten: Logbetrachter (roles/logging.viewer)

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 Boot-Sequenz fehlgeschlagen sind

Beim Integritätsmonitoring wird ein Log in Logging hinzugefügt, wenn eine VM der Steuerungsebene eine Phase der Bootsequenz nicht besteht oder erfolgreich durchläuft. Führen Sie die folgenden Befehle aus, um fehlgeschlagene Boot-Vorgänge aufzurufen:

Rufen Sie in der Cloud de Confiance Console die Seite Log-Explorer auf:

Zum Log-Explorer

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.

Klicken Sie auf Abfrage ausführen. Wenn keine Ergebnisse angezeigt werden, haben Ihre 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.
Kopieren Sie im fehlgeschlagenen Boot-Integritätslog den Wert im Feld resource.labels.instance_id.

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.

Klicken Sie auf Abfrage ausführen. Der Wert im Feld protoPayload.metadata.parentResource.parentResourceId ist die GKE-Cluster-ID.
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 IhrerCloud de Confiance -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 Cloud de Confiance .
- LOCATION: Der Standort des Clusters.
- CLUSTER_NAME ist der Name des Clusters.

VM-Logs der Steuerungsebene suchen und prüfen

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

Rufen Sie in der Cloud de Confiance Console die Seite Log-Explorer auf:

Zum Log-Explorer

Geben Sie im Feld Abfrage die folgende Abfrage ein:

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

Klicken Sie auf Abfrage ausführen. Wenn Sie keine Ergebnisse sehen, prüfen Sie, ob Sie alle Voraussetzungen im Abschnitt Vorbereitung erfüllen.
Sehen Sie sich in den Abfrageergebnissen das Feld metadata an. 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, dasCloud de Confiancegehö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 suchen 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 Controlplane-VM:

Die VM-Image-ID
Die Projektnummer des Projekts, das zu Cloud de Confiancegehö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, also der String nach /images/ im Feld attachedDisks.sourceImage im VM-Prüfprotokoll aus dem vorherigen Abschnitt. Beispiel: gke-1302-gke1627000-cos-113-18244-85-49-c-pre.
IMAGE_ID: die VM-Image-ID, die der Wert des Felds attachedDisks.sourceImageId im VM-Audit-Log aus dem vorherigen Abschnitt ist. Beispiel: 9046093115864736653.

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

Öffnen Sie das gke-vsa-GitHub-Repository.
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.
Laden Sie die VSA-Datei herunter.
Installieren Sie das slsa-verifier-Tool.

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

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 VSA-Datei, die Sie heruntergeladen haben.
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

Erfahren Sie, was Sie sonst noch in der Steuerungsebene anzeigen können.