Some or all of the information on this page might not apply to Trusted Cloud by S3NS.

Diese Seite wurde von der Cloud Translation API übersetzt.

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

Autopilot Standard

In diesem Leitfaden wird beschrieben, wie Sie die Integrität des Compute Engine-VM-Images (virtuelle Maschine) überprüfen, das von Google Kubernetes Engine (GKE) für VMs der Steuerungsebene verwendet wird. Diese Anleitung richtet sich an ein Sicherheitsteam, das die Logs der Steuerungsebene überwacht und Folgendes überprüfen möchte:

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

Sie können diese Überprüfung auch für die Betriebssystem-Images und die Boot-Integrität Ihrer Worker-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 wendet Trusted Cloud verschiedene Sicherheitsmaßnahmen auf die verwaltete Steuerungsebene an. 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 vTPM (Virtual Trusted Platform Module) und UEFI-Firmware verwenden. Auf allen GKE-Knoten ist auch das Integritätsmonitoring aktiviert, das die Startsequenz jeder Shielded VM mit einer Baseline-Startsequenz vergleicht, die als „gut“ eingestuft wird. 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. Das Integritätsmonitoring 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-Logs als earlyBootReportEvent hinzugefügt.
Späte Startsequenz: vom Zeitpunkt, an dem der Bootloader die Kontrolle übernimmt, bis der Betriebssystem-Kernel die Kontrolle übernimmt. Wird den VM-Logs als lateBootReportEvent hinzugefügt.

GKE fügt auch Logs zur Erstellung von VMs der Steuerungsebene zu Logging hinzu. Diese Logs enthalten Metadaten, die den Computer identifizieren, sowie Details zum VM-Image und zur Bootsequenz. Trusted Cloud veröffentlicht eine Zusammenfassungsbestätigung der Überprüfung (Verification Summary Attestation, VSA) für jedes GKE-Steuerungsebenen-VM-Image im gke-vsa-Repository auf GitHub. Das VSA verwendet das in-toto-Framework für Atteste. 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, dem beabsichtigten Quellcode entspricht und genau dem Image entspricht, das andere Trusted Cloud 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.

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.
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. Durch das Festlegen eines Standardspeicherorts können Sie in der gcloud CLI Fehler wie One of [--zone, --region] must be supplied: Please specify location vermeiden. Bei bestimmten Befehlen müssen Sie möglicherweise den Speicherort angeben, wenn er sich von dem von Ihnen festgelegten Standard unterscheidet.

Enable the Cloud Logging API.
Enable the API
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 Ihr Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Prüfen der Integrität der Steuerungsebene-VM benötigen:

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 Startvorgänge aufzurufen:

Rufen Sie in der Trusted Cloud 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-Ereignissen 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ätsüberprüfungen bestanden. Wenn Sie eine Ausgabe sehen, fahren Sie mit dem nächsten Schritt fort, um den entsprechenden Cluster zu identifizieren.
Kopieren Sie im Protokoll für die fehlgeschlagene Boot-Integrität 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 IhrerTrusted 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: Ihre Trusted Cloud -Projekt-ID.
- LOCATION: Der Standort des Clusters.
- CLUSTER_NAME ist der Name des Clusters.

Logs der VM der Steuerungsebene suchen und prüfen

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

Rufen Sie in der Trusted Cloud 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 keine Ergebnisse angezeigt werden, 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, dasTrusted Cloudgehört und die VMs der Steuerungsebene hostet, 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 dem VM-Image der Steuerungsebene im Repository „gke-vsa“ 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 prü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 die VMs enthält und zu Trusted Cloudgehört.
Der Name des Betriebssystem-Images, das zum Booten der VM verwendet 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, 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-Prüfprotokoll 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 überprü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 Prüfungen besteht, sieht die Ausgabe so aus:

Verifying VSA: PASSED
PASSED: SLSA verification passed

Nächste Schritte

Weitere Informationen