Fehlerbehebung bei der Authentifizierung von Arbeitslasten

In diesem Dokument wird beschrieben, wie Sie häufige Fehler im Zusammenhang mit der Authentifizierung von Arbeitslasten über mTLS bei anderen Arbeitslasten 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 so 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 die 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 zwischen 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 diese Funktion 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 eine neue VM, die die Authentifizierung zwischen Arbeitslasten unterstützt. Verwenden Sie dazu eine der folgenden Methoden:

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

  2. 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 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 in den Dienstprotokollen, ob gce-workload-cert-refresh.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.

  1. 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 VM-Metadaten aktiviert ist, enthält die Protokolldatei die Fehlermeldung workload certificate feature not enabled.

    Um dieses Problem zu beheben, erstellen Sie mit einer der folgenden Methoden eine neue VM, die die Authentifizierung zwischen Arbeitslasten 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 Vertrauenseinstellung auftreten. Wenn solche Fehler auftreten, aktualisieren Sie die Konfigurationswerte. Folgen Sie dazu der Anleitung unter Zertifizierungsausgabe und Vertrauensstellung konfigurieren.

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

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

  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 folgendem entsprechen:

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

    Im vorherigen Beispiel:

    • 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-identity falsch ist, müssen Sie eine neue VM mit dem richtigen Wert erstellen, da der Wert für die verwaltete Identität nur beim Erstellen der VM 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, die der SPIFFE-vertrauenswürdigen Domain auf der der VM zugewiesenen verwalteten Identität entspricht. Weitere Informationen finden Sie unter Vertrauenskonfiguration definieren.

  6. Wenn die config_status-Datei 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 aktivierter Funktion oder eine neue Instanzvorlage und eine 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: 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, 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 diese Werte nicht 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 den folgenden Anforderungen entspricht:

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