In diesem Dokument wird beschrieben, wie Sie häufige Fehler im Zusammenhang mit der Authentifizierung von Arbeitslasten über mTLS bei anderen Arbeitslasten beheben.
Weitere Informationen finden Sie unter Fehlerbehebung bei der Identitätsföderation von Arbeitslasten.
Hinweis
-
Richten Sie die Authentifizierung ein, falls Sie dies noch nicht getan haben.
Bei der Authentifizierung wird Ihre Identität für den Zugriff auf Google Cloud Dienste und APIs überprüft. Zur Ausführung von Code oder Beispielen aus einer lokalen Entwicklungsumgebung können Sie sich so bei Compute Engine authentifizieren:
-
Installieren Sie die Google Cloud CLI. Initialisieren Sie die Google Cloud CLI nach der Installation mit dem folgenden Befehl:
gcloud initWenn Sie einen externen Identitätsanbieter (IdP) verwenden, müssen Sie sich zuerst mit Ihrer föderierten Identität in der gcloud CLI anmelden.
- Legen Sie eine Standardregion und -zone fest.
-
Das generierte Anmeldedatenverzeichnis ist nicht vorhanden
Wenn Sie die Fehlermeldung erhalten, dass das Verzeichnis /var/run/secrets/workload-spiffe-credentials nicht vorhanden ist, gehen Sie so vor:
Prüfen Sie, ob Ihre Compute-Instanz die Authentifizierung zwischen Arbeitslasten unterstützt. Verwenden Sie dazu eine der folgenden Schnittstellen, um zu prüfen, ob verwaltete Arbeitslastidentitäten aktiviert sind:
Console
Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.
Klicken Sie auf der Seite VM-Instanzen in der Spalte Name auf den Instanznamen, um weitere Details zur Instanz aufzurufen.
Prüfen Sie auf der Seite Details im Abschnitt Sicherheit und Zugriff, ob für „Workload Identity-Zertifikate“ der Wert „Aktiviert“ festgelegt ist.
gcloud
Mit dem
gcloud alpha compute instances describe-Befehl können Sie prüfen, ob die Funktion für verwaltete Workload-Identitäten für eine Compute-Instanz aktiviert ist.gcloud alpha compute instances describe INSTANCE_NAME \ --zone=ZONE \ --format="table(name,zone,identityCertificate)"Ersetzen Sie Folgendes:
INSTANCE_NAME: der Name der Instanz.ZONE: die Zone, in der sich die Instanz befindet.
REST
Wenn Sie die Details einer Compute-Instanz aufrufen möchten, senden Sie eine
GET-Anfrage an die Methodeinstances.get. Wenn Sie der Anfrage einen$fields-Abfrageparameter hinzufügen, können Sie die Ausgabe auf die gewünschten Felder beschränken.GET https://compute.googleapis.com/compute/alpha/projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME$fields=name,identityCertificate,identity
Ersetzen Sie Folgendes:
PROJECT_ID: die ID des Projekts, in dem sich die Instanz befindetZONE: die Zone, in der sich die Instanz befindet.INSTANCE_NAMEden Namen der Instanz
Prüfen Sie die Instanzwerte für
identityCertificateundidentity.Wenn die
identityCertificate-Property auffalsegesetzt ist, wird diese Funktion von dieser Compute-Instanz nicht unterstützt.Erstellen Sie eine neue Instanz, die die Authentifizierung zwischen Arbeitslasten unterstützt, um dieses Problem zu beheben. Weitere Informationen finden Sie unter Verwaltete Arbeitslastidentitäten auf vorhandenen VMs aktivieren.
Auf der VM muss ein Gastbetriebssystem mit der Compute Engine-Gast-Agent-Version 20231103.01 oder höher ausgeführt werden. Verwenden Sie die gcloud CLI, um die Ausgabe des seriellen Ports aufzurufen und die aktuelle Version des Compute Engine-Gast-Agents zu ermitteln:
gcloud compute instances get-serial-port-output INSTANCE_NAME | grep "GCE Agent Started"Ersetzen Sie INSTANCE_NAME durch den Namen der Compute-Instanz.
Informationen zum Aktualisieren des Compute Engine-Gast-Agents finden Sie unter Gastumgebung aktualisieren.
Prüfen Sie in den Dienstprotokollen, ob der
gce-workload-cert-refresh.timer-Systemd-Timer die Anmeldedaten für die Arbeitslast und das Trust-Bundle abrufen konnte.# View timer logs to see when the gce-workload-cert-refresh.timer last ran journalctl -u gce-workload-cert-refresh.timer # View service logs from gce-workload-cert-refresh.service journalctl -u gce-workload-cert-refresh.service
Das generierte Anmeldedatenverzeichnis enthält nur die Datei config_status
Das generierte Anmeldedatenverzeichnis /var/run/secrets/workload-spiffe-credentials enthält aus verschiedenen Gründen möglicherweise nur die config_status. Mit den folgenden Schritten können Sie dieses Problem beheben.
Prüfen Sie den Inhalt der Datei
config_status, um sicherzustellen, dass das Feature für verwaltete Arbeitslastidentitäten aktiviert ist. Wenn die Funktion nicht mit den entsprechenden Werten aktiviert ist, enthält die Protokolldatei die Fehlermeldungworkload certificate feature not enabled.Um dieses Problem zu beheben, erstellen Sie mit einer der folgenden Methoden eine neue Compute-Instanz, die die Authentifizierung zwischen Arbeitslasten unterstützt:
Prüfen Sie den Inhalt der Datei
config_status, um sicherzustellen, dass keine Fehler aufgrund fehlender Attributwerte oder einer ungültigen Konfiguration für die Zertifikatausstellung oder die Vertrauenseinstellung auftreten. Wenn solche Fehler auftreten, aktualisieren Sie die Konfigurationswerte. Folgen Sie dazu der Anleitung unter Zertifizierungsausgabe und Vertrauensstellung konfigurieren.Prüfen Sie, ob den verwalteten Arbeitslastidentitäten im Workload Identity-Pool die richtigen Berechtigungen für den Zugriff auf die untergeordneten CA-Pools erteilt wurden. Verwenden Sie den folgenden Befehl:
gcloud privateca pools get-iam-policy SUBORDINATE_CA_POOL_ID \ --location=SUBORDINATE_CA_POOL_REGION
Ersetzen Sie Folgendes:
- SUBORDINATE_CA_POOL_ID: die ID für den untergeordneten CA-Pool.
- SUBORDINATE_CA_POOL_REGION: die Region des untergeordneten CA-Pools.
Die Ausgabe dieses Befehls sollte Folgendes enthalten:
bindings: - members: - principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/name/locations/global/workloadIdentityPools/POOL_ID/* - role: roles/privateca.poolReader - members: - principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/name/locations/global/workloadIdentityPools/POOL_ID/* role: roles/privateca.workloadCertificateRequesterIm vorherigen Beispiel gilt:
- PROJECT_NUMBER ist die Projektnummer Ihres Projekts.
- POOL_ID: die ID des Workload Identity-Pools
Wenn Sie keine ähnliche Ausgabe wie im vorherigen Beispiel sehen, gewähren Sie die erforderlichen Berechtigungen wie unter Verwaltete Arbeitslastidentitäten autorisieren, um Zertifikate vom CA-Pool anzufordern beschrieben.
Wenn die Datei
config_statuskeine Fehlermeldungen enthält, prüfen Sie den Wert voniam.googleapis.com/workload-identityin der Datei.Der Wert sollte folgendem entsprechen:spiffe://POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID
Im vorherigen Beispiel gilt:
- PROJECT_NUMBER ist die Projektnummer des Projekts, das den verwalteten Workload Identity-Pool enthält.
- POOL_ID: die ID des Workload Identity-Pools
- NAMESPACE_ID ist die ID des Namespace im Workload Identity-Pool.
- MANAGED_IDENTITY_ID ist die ID der verwalteten Arbeitslastidentität.
Wenn der Wert für
iam.googleapis.com/workload-identityfalsch ist, müssen Sie eine neue Compute-Instanz mit dem richtigen Wert erstellen, da der Wert für die verwaltete Identität nur beim Erstellen der Instanz aktualisiert werden kann.Wenn die Datei
config_statuskeine Fehlermeldungen enthält, prüfen Sie, ob die Vertrauenskonfiguration einen gültigen Eintrag für die SPIFFE-vertrauenswürdige DomainPOOL_ID.global.PROJECT_NUMBER.workload.id.googenthält, die der SPIFFE-vertrauenswürdigen Domain auf der der Compute-Instanz zugewiesenen verwalteten Identität entspricht. Weitere Informationen finden Sie unter Vertrauenskonfiguration definieren.Wenn die
config_status-Datei Fehlermeldungen mit dem FehlercodeINTERNAL_ERRORenthält, wenden Sie sich mit der Fehlermeldung an Cloud Customer Care oder Ihren Google Cloud -Ansprechpartner.