In diesem Dokument wird beschrieben, wie Sie Secure Boot oder ein virtualisiertes Trusted Platform Module (vTPM) auf einer VM-Instanz in Google Distributed Cloud (GDC) mit Air Gap aktivieren.
Dieses Dokument richtet sich an Entwickler in Plattformadministrator- oder Anwendungsoperatorgruppen, die Secure Boot und vTPMs auf VMs in einer GDC-Umgebung konfigurieren. Weitere Informationen finden Sie unter Zielgruppen für die Dokumentation zu GDC mit Air Gap.
Informationen zu Secure Boot
Secure Boot ist eine Funktion, die dafür sorgt, dass das System nur authentische Software ausführt. Dazu wird die digitale Signatur aller Bootkomponenten überprüft und der Vorgang angehalten, wenn die Überprüfung fehlschlägt. Dabei wird die UEFI-Firmware (Unified Extensible Firmware Interface) verwendet, um Zertifikate und Schlüssel zu verwalten, mit denen Hersteller Systemfirmware, Bootloader und geladene Binärdateien signieren.
Bei jedem Bootvorgang verifiziert die UEFI-Firmware die digitale Signatur jeder Komponente anhand gespeicherter genehmigter Schlüssel und blockiert alle nicht oder nicht ordnungsgemäß signierten Komponenten.
Wenn Sie Secure Boot auf Ihrer VM-Instanz aktivieren möchten, müssen Sie das Feld shieldConfig.bootType der VM auf uefi und shieldConfig.enableSecureBoot auf true setzen.
Die offizielle UEFI-Dokumentation finden Sie unter https://uefi.org/sites/default/files/resources/UEFI_Secure_Boot_in_Modern_Computer_Security_Solutions_2013.pdf.
Informationen zu Virtual Trusted Platform Modules
Ein vTPM ist ein spezieller virtueller Computerchip, der die Schlüssel und Zertifikate schützt, die zur Authentifizierung des Systemzugriffs verwendet werden. Weitere Informationen zu vTPMs finden Sie unter https://trustedcomputinggroup.org/trusted-platform-module-tpm-summary/.
Sie können ein vTPM auch verwenden, um Secrets durch Abschirmung oder Versiegelung zu schützen. Weitere Informationen zu versiegeltem Speicher finden Sie unter https://en.wikipedia.org/wiki/Trusted_Computing#SEALED-STORAGE. Beispiele für die Go-Sprache, die die Verwendung eines vTPM für diesen Zweck veranschaulichen, finden Sie im Go-TPM-Projekt auf GitHub unter https://github.com/google/go-tpm.
Hinweis
Wenn Sie gdcloud-Befehlszeilenbefehle verwenden möchten, müssen Sie die gdcloud-Befehlszeile heruntergeladen, installiert und konfiguriert haben.
Alle Befehle für Distributed Cloud verwenden die gdcloud- oder kubectl-Befehlszeile und erfordern eine Betriebssystemumgebung.
Pfad der kubeconfig-Datei abrufen
Wenn Sie Befehle auf dem Management API-Server ausführen möchten, benötigen Sie die folgenden Ressourcen:
Melden Sie sich an und generieren Sie die kubeconfig-Datei für den Management API-Server, falls Sie noch keine haben.
Verwenden Sie den Pfad zur kubeconfig-Datei des Management API-Servers, um
MANAGEMENT_API_SERVERin dieser Anleitung zu ersetzen.
IAM-Rollen anfordern
Bitten Sie Ihren IAM-Projektadministrator, Ihnen die Rolle „Virtual Machine Project Admin“ (project-vm-admin) zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Aktivieren von Secure Boot oder vTPM auf Ihrer VM benötigen.
Alle VM-Rollen müssen an den Namespace des Projekts gebunden sein, in dem sich die VM befindet. Folgen Sie der Anleitung, um Ihren Zugriff zu bestätigen.
Secure Boot aktivieren
Secure Boot für eine VM aktivieren. Folgen Sie der Anleitung für eine VM mit dem Namen VM_NAME im Namespace des Projekts (PROJECT_NAMESPACE).
Beenden Sie die VM, falls sie ausgeführt wird, bevor Sie den Patch anwenden. Wenn Sie versuchen,
shieldConfigzu patchen, während die VM ausgeführt wird, gibt die API den FehlerForbiddenzurück:Changes to shieldConfig are not allowed while the VM is running. Eine Anleitung finden Sie unter VM beenden.Aktualisieren Sie die benutzerdefinierte VM-Ressource, um Secure Boot zu aktivieren:
kubectl --kubeconfig MANAGEMENT_API_SERVER \ -n PROJECT_NAMESPACE \ patch virtualmachines.virtualmachine.gdc.goog VM_NAME \ --type merge --patch $' spec: shieldConfig: bootType: uefi enableSecureBoot: true 'Ersetzen Sie die folgenden Variablen:
MANAGEMENT_API_SERVER: die kubeconfig-Datei für den Verwaltungs-API-Server.PROJECT_NAMESPACE: der Namespace des Projekts, in dem sich die VM befindet.VM_NAME: der Name der VM.
Nachdem Sie den Patch erfolgreich angewendet haben, starten Sie die VM gemäß der Anleitung zum Starten einer VM.
Prüfen Sie, ob Secure Boot aktiviert ist. Stellen Sie eine SSH-Verbindung zu Ihrer VM her und führen Sie den folgenden Befehl aus:
mokutil --sb-stateWenn Sie Secure Boot erfolgreich aktiviert haben, gibt der Befehl
SecureBoot enabledzurück.Wenn das
mokutil-Tool meldet, dass Secure Boot nicht aktiviert ist, führen Sie die Schritte im Abschnitt Fehlerbehebung bei der Secure Boot-Konfiguration aus.
Fehlerbehebung bei der Secure Boot-Konfiguration
Öffnen Sie die benutzerdefinierte VM-Ressource in einem Editor:
kubectl --kubeconfig MANAGEMENT_API_SERVER \ -n PROJECT_NAMESPACE \ edit virtualmachines.virtualmachine.gdc.goog VM_NAMEErsetzen Sie die folgenden Variablen:
MANAGEMENT_API_SERVER: die kubeconfig-Datei für den Verwaltungs-API-Server.PROJECT_NAMESPACE: der Namespace des Projekts, in dem sich die VM befindet.VM_NAME: der Name der VM.
Suchen Sie nach fehlenden Feldern oder Werten, wie im Feld
specunter Secure Boot aktivieren gezeigt. Diese sind erforderlich.Wenn Felder fehlen oder falsch sind, bearbeiten Sie
spec, um die fehlenden Felder hinzuzufügen und fehlerhafte Werte zu korrigieren.Speichern Sie die Datei.
Folgen Sie der Anleitung unter VM neu starten.
Wenn das Problem durch die vorherigen Schritte nicht behoben wird, prüfen Sie in der Dokumentation zum Betriebssystem der VM, ob die Betriebssystemversion Secure Boot unterstützt.
vTPM aktivieren
vTPM für eine VM aktivieren Folgen Sie der Anleitung für eine VM mit dem Namen VM_NAME im Namespace des Projekts (PROJECT_NAMESPACE).
Beenden Sie die VM, falls sie ausgeführt wird, bevor Sie den Patch anwenden. Wenn Sie versuchen,
shieldConfigzu patchen, während die VM ausgeführt wird, gibt die API den FehlerForbiddenzurück:Changes to shieldConfig are not allowed while the VM is running. Eine Anleitung finden Sie unter VM beenden.Aktualisieren Sie die benutzerdefinierte VM-Ressource, um vTPM zu aktivieren:
kubectl --kubeconfig MANAGEMENT_API_SERVER \ -n PROJECT_NAMESPACE \ patch virtualmachines.virtualmachine.gdc.goog VM_NAME \ --type merge --patch $' spec: shieldConfig: enableVtpm: true 'Ersetzen Sie die folgenden Variablen:
MANAGEMENT_API_SERVER: die kubeconfig-Datei für den Verwaltungs-API-Server.PROJECT_NAMESPACE: der Namespace des Projekts, in dem sich die VM befindet.VM_NAME: der Name der VM.
Nachdem Sie den Patch erfolgreich angewendet haben, starten Sie die VM gemäß der Anleitung zum Starten einer VM.
Prüfen Sie, ob vTPM aktiviert ist. Stellen Sie eine SSH-Verbindung zu Ihrer VM her und führen Sie den folgenden Befehl aus:
dmesg | grep -i tpmWenn Sie vTPM erfolgreich aktiviert haben, gibt der Befehl das TPM-Modul als Teil der ACPI-Tabellen zurück. Die Ausgabe sieht etwa so aus:
[ 7.620985] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1, rev-id 1)Wenn die
ACPI tablesdas TPM-Modul nicht anzeigen, folgen Sie der Anleitung im Abschnitt Fehlerbehebung bei der vTPM-Konfiguration.
Fehlerbehebung bei der vTPM-Konfiguration
Öffnen Sie die benutzerdefinierte VM-Ressource in einem Editor:
kubectl --kubeconfig MANAGEMENT_API_SERVER \ -n PROJECT_NAMESPACE \ edit virtualmachines.virtualmachine.gdc.goog VM_NAMEErsetzen Sie die folgenden Variablen:
MANAGEMENT_API_SERVER: die kubeconfig-Datei für den Verwaltungs-API-Server.PROJECT_NAMESPACE: der Namespace des Projekts, in dem sich die VM befindet.VM_NAME: der Name der VM.
Suchen Sie nach fehlenden Feldern oder Werten, wie im Feld
specunter vTPM aktivieren gezeigt. Diese sind erforderlich.Wenn Felder fehlen oder falsch sind, bearbeiten Sie
spec, um die fehlenden Felder hinzuzufügen und fehlerhafte Werte zu korrigieren.Speichern Sie die Datei.
Folgen Sie der Anleitung unter VM neu starten.
Wenn das Problem durch die vorherigen Schritte nicht behoben wird, prüfen Sie in der Dokumentation zum Betriebssystem der VM, ob die Betriebssystemversion vTPM unterstützt.