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.

Weitere Informationen finden Sie unter Fehlerbehebung bei der Identitätsföderation von Arbeitslasten.

Hinweis

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

    1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.

      Zur Seite „VM-Instanzen“

    2. Klicken Sie auf der Seite VM-Instanzen in der Spalte Name auf den Instanznamen, um weitere Details zur Instanz aufzurufen.

    3. 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 Methode instances.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 befindet

    • ZONE: die Zone, in der sich die Instanz befindet.

    • INSTANCE_NAME den Namen der Instanz

  2. Prüfen Sie die Instanzwerte für identityCertificate und identity.

  3. Wenn die identityCertificate-Property auf false gesetzt 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.

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

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

  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 Werten 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 Compute-Instanz, 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/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.workloadCertificateRequester
    

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

  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 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-identity falsch 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.

  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 Compute-Instanz 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.