Fehlerbehebung bei der Authentifizierung von Arbeitslasten zu Arbeitslasten

In diesem Dokument wird beschrieben, wie Sie häufige Fehler im Zusammenhang mit der Authentifizierung von Arbeitslasten bei anderen Arbeitslasten über mTLS beheben.

Hinweise

  • 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 wie folgt bei Compute Engine authentifizieren.

    1. Install the Google Cloud CLI, then initialize it by running the following command: 

      gcloud init
    2. Set a default region and zone.

Das generierte Anmeldedatenverzeichnis ist nicht vorhanden

Wenn Sie eine Fehlermeldung erhalten, dass das Verzeichnis /var/run/secrets/workload-spiffe-credentials nicht vorhanden ist, gehen Sie so vor:

  1. Prüfen Sie, ob Ihre VM die Authentifizierung von Arbeitslasten zu Arbeitslasten unterstützt. Führen Sie dazu den folgenden Befehl in der VM aus.

    curl  "http://metadata.google.internal/computeMetadata/v1/instance/gce-workload-certificates/config-status" -H "Metadata-Flavor: Google"

    1. Wenn die Antwort ein HTTP 404-Fehlercode mit der folgenden Fehlermeldung ist, unterstützt diese VM dieses Feature nicht.

      The requested URL /computeMetadata/v1/instance/gce-workload-certificates/config-status
was not found on this server.  That's all we know.

      Erstellen Sie zur Behebung eine neue VM, die die Arbeitslast-zu-Arbeitslast-Authentifizierung mit einer der folgenden Methoden unterstützt:

    2. Wenn die Antwort ein HTTP 404-Fehlercode mit der Fehlermeldung workload certificate feature not enabled ist, unterstützt die VM verwaltete Arbeitslastidentitäten, das Feature ist jedoch nicht aktiviert. Informationen zum Aktivieren des Features auf der VM finden Sie unter Verwaltete Arbeitslastidentitäten auf vorhandenen VMs aktivieren.

  2. Prüfen Sie, ob auf der VM ein Gastbetriebssystem mit der Compute Engine-Gast-Agent-Version 20231103.01 oder höher ausgeführt wird. Verwenden Sie die gcloud CLI, um die Ausgabe des seriellen Ports anzusehen und so die aktuelle Version des Compute Engine-Gast-Agents zu ermitteln:

    gcloud compute instances get-serial-port-output VM_NAME | grep "GCE Agent Started"

    Ersetzen Sie VM_NAME durch den Namen der VM.

    Informationen zum Aktualisieren des Compute Engine-Gast-Agents finden Sie unter Gastumgebung aktualisieren.

  3. Prüfen Sie anhand der Dienstlogs, ob der gce-workload-cert-refresh.timer die Anmeldedaten der Arbeitslast und das Vertrauens-Bundle erfolgreich 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 kann aus verschiedenen Gründen nur den config_status enthalten. Führen Sie die folgenden Schritte aus, um das Problem zu beheben.

  1. Prüfen Sie den Inhalt der Datei config_status, um sicherzustellen, dass das Feature für verwaltete Arbeitslastidentitäten aktiviert ist. Wenn das Feature nicht mit den entsprechenden VM-Metadaten aktiviert wird, enthält die Logdatei die Fehlermeldung workload certificate feature not enabled.

    Erstellen Sie zur Behebung dieses Problems eine neue VM, die die Arbeitslast-zu-Arbeitslastauthentifizierung mit einer der folgenden Methoden unterstützt:

  2. 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 Vertrauenskonfiguration vorliegen. Wenn solche Fehler vorliegen, aktualisieren Sie die Konfigurationswerte, indem Sie die Schritte unter Zertifikatsausstellung und Vertrauenskonfiguration aktualisieren ausführen.

  3. 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 ist die ID des untergeordneten CA-Pools.
    • SUBORDINATE_CA_POOL_REGION ist die Region des untergeordneten CA-Pools.

    Die Ausgabe dieses Befehls sollte Folgendes enthalten:

    bindings:
- members:
  - principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/*
  -
  role: roles/privateca.poolReader
- members:
  - principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/*
  role: roles/privateca.workloadCertificateRequester

    Im vorherigen Beispiel gilt:

    • PROJECT_NUMBER ist die Projektnummer Ihres Projekts.
    • POOL_ID: die ID des Workload Identity-Pools

    Wenn keine Ausgabe wie im vorherigen Beispiel angezeigt wird, erteilen Sie die erforderlichen Berechtigungen, wie unter Verwaltete Arbeitslastidentitäten autorisieren, um Zertifikate vom CA-Pool anzufordern beschrieben.

  4. Wenn die Datei config_status keine Fehlermeldungen enthält, prüfen Sie den Wert von iam.googleapis.com/workload-identity in der Datei.Der Wert sollte so übereinstimmen:

    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 Workload Identity.

    Wenn der Wert für iam.googleapis.com/workload-identity falsch ist, müssen Sie eine neue VM mit dem richtigen Wert erstellen, da der Wert der verwalteten Identität nur während der VM-Erstellung aktualisiert werden kann.

  5. Wenn die Datei config_status keine Fehlermeldungen enthält, prüfen Sie, ob die Vertrauenskonfiguration einen gültigen Eintrag für die SPIFFE-vertrauenswürdige Domain POOL_ID.global.PROJECT_NUMBER.workload.id.goog enthält, der der SPIFFE-vertrauenswürdigen Domain auf der verwaltete Identität der VM zugewiesen ist. Weitere Informationen finden Sie unter Vertrauenskonfiguration definieren.

  6. Wenn die Datei config_status Fehlermeldungen mit dem Fehlercode INTERNAL_ERROR enthält, wenden Sie sich mit der Fehlermeldung an Cloud Customer Care oder Ihren Google Cloud-Ansprechpartner.

Beim Abfragen von Metadatenserver-Endpunkten wird ein 404-Fehler zurückgegeben

Wenn Sie bei der Abfrage des Endpunkts workload-identities oder trust-anchors eine 404-Antwort erhalten, prüfen Sie, ob die VM die verwalteten Arbeitslastidentitäten unterstützt. Führen Sie dazu den folgenden Befehl in der VM aus:

curl  "http://metadata.google.internal/computeMetadata/v1/instance/gce-workload-certificates/config-status" -H "Metadata-Flavor: Google"

  • Wenn die Antwort ein HTTP-404-Fehlercode mit der folgenden Fehlermeldung ist:

      The requested URL /computeMetadata/v1/instance/gce-workload-certificates/config-status
  was not found on this server.  That's all we know.

    Die VM unterstützt keine verwalteten Arbeitslastidentitäten. Führen Sie einen der folgenden Schritte aus, um das Problem zu lösen:

  • Wenn die Antwort ein HTTP-404-Fehlercode mit der Fehlermeldung workload certificate feature not enabled ist, unterstützt diese VM verwaltete Arbeitslastidentitäten, aber das Feature ist nicht aktiviert. Erstellen Sie eine neue VM mit aktiviertem Feature oder erstellen Sie eine neue Instanzvorlage und eine neue verwaltete Instanzgruppe.

  • Prüfen Sie mit dem folgenden Befehl, ob dem Workload Identity-Pool die richtigen Berechtigungen für den Zugriff auf die untergeordneten CA-Pools erteilt wurden:

    gcloud privateca pools get-iam-policy SUBORDINATE_CA_POOL_ID \
  --location=SUBORDINATE_CA_POOL_REGION

    Ersetzen Sie Folgendes:

    • SUBORDINATE_CA_POOL_ID ist die ID des untergeordneten CA-Pools.
    • SUBORDINATE_CA_POOL_REGION ist die Region des untergeordneten CA-Pools.

    Die Ausgabe dieses Befehls sollte Folgendes enthalten, wobei PROJECT_NUMBER die Projektnummer Ihres Projekts und POOL_ID die ID des Workload Identity-Pools ist.

    bindings:
- members:
- principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/*
- role: roles/privateca.poolReader
- members:
- principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/*
- role: roles/privateca.workloadCertificateRequester

    Wenn Ihre Ausgabe nicht diese Werte enthält, gewähren Sie die richtigen Berechtigungen, wie unter Verwaltete Arbeitslastidentitäten autorisieren, um Zertifikate vom CA-Pool anzufordern beschrieben.

  • Prüfen Sie, ob der Wert von iam.googleapis.com/workload-identity korrekt ist und mit Folgendem übereinstimmt:

    spiffe://POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID

    Wenn der Wert nicht übereinstimmt, müssen Sie eine neue VM erstellen, da der Wert der verwalteten Identität nach dem Erstellen der VM nicht aktualisiert werden kann.

  • Achten Sie darauf, dass die Vertrauenskonfiguration einen gültigen Eintrag für die SPIFFE-vertrauenswürdige Domain POOL_ID.global.PROJECT_NUMBER.workload.id.goog enthält, die der SPIFFE-vertrauenswürdigen Domain auf der der VM zugewiesenen verwalteten Identität entspricht.