Fehler beheben

Auf dieser Seite erfahren Sie, wie Sie Probleme mit Secure Source Manager beheben.

Fehlermeldung beim Erstellen eines Repositorys

Der folgende Fehler wird angezeigt, wenn Sie versuchen, ein Repository zu erstellen:

There was an error while loading /repo/create. Try refreshing the page.

Dieses Problem tritt auf, wenn:

  • die Secure Source Manager API in Ihrem Projekt nicht aktiviert ist.
  • Sie nicht die Rolle „Repo-Administrator“ für Ihr Projekt haben oder nicht berechtigt sind, Repositorys in der Secure Source Manager-Instanz zu erstellen.

So beheben Sie dieses Problem:

  • Aktivieren Sie die Secure Source Manager API in Ihrem Projekt.
  • Bitten Sie Ihren Administrator, Ihnen die folgenden Rollen zu gewähren:
    • Rolle „Repo-Administrator“ (roles/securesourcemanager.repoAdmin) für Ihr Projekt
    • Rolle „Instanz-Accessor“ (roles/securesourcemanager.instanceAccessor) für die Secure Source Manager-Instanz
    • Rolle „Ersteller von Instanz-Repositorys“ (roles/securesourcemanager.instanceRepositoryCreator) für die Secure Source Manager-Instanz

Weitere Informationen finden Sie unter Zugriffssteuerung mit IAM.

Fehlermeldung beim Klonen eines Repositorys auf einem Mac

Der folgende Fehler wird angezeigt, wenn Sie versuchen, ein Repository zu klonen:

git: 'credential-gcloud.sh' is not a git command.  See 'git --help'.
fatal: Authentication failed for [repo-url]

Dieses Problem tritt auf, wenn:

  • die gcloud CLI mit Homebrew oder einer anderen nicht standardmäßigen Installation installiert wurde.
  • git-credential-gcloud.sh nicht zu Ihrem PATH hinzugefügt wurde.

So beheben Sie dieses Problem:

  • Führen Sie source $HOMEBREW_PREFIX/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/path.zsh.inc aus.

  • Prüfen Sie mit dem folgenden Befehl, ob git-credential-gcloud.sh in Ihrem Pfad enthalten ist:

    which git-credential-gcloud.sh

SSH-Verbindung schlägt mit dem Fehler „no matching“ fehl

Wenn Sie Git-Vorgänge über SSH ausführen, wird möglicherweise eine der folgenden Fehlermeldungen angezeigt:

  • Unable to negotiate with <host> port <port>: no matching key exchange method found.
  • Unable to negotiate with <host> port <port>: no matching cipher found.
  • Unable to negotiate with <host> port <port>: no matching MAC found.

Dieses Problem tritt auf, wenn Ihr SSH-Client die von Secure Source Manager benötigten kryptografischen Algorithmen nicht unterstützt. Das kann passieren, wenn Sie einen älteren SSH-Client verwenden oder Ihr Client nicht für die Verwendung unterstützter Algorithmen konfiguriert ist.

Für Secure Source Manager ist einer der folgenden Algorithmen erforderlich:

  • Schlüsselaustauschalgorithmen:curve25519-sha256, diffie-hellman-group14-sha256
  • Verschlüsselungen:chacha20-poly1305@openssh.com, aes128-ctr, aes192-ctr, aes256-ctr, aes128-gcm@openssh.com, aes256-gcm@openssh.com
  • MACs: hmac-sha2-256-etm@openssh.com, hmac-sha2-256

Aktualisieren Sie Ihren SSH-Client auf eine aktuelle Version, die diese Algorithmen unterstützt, um dieses Problem zu beheben.

Git-HTTPS-Anfragen schlagen mit dem Fehler „permission denied“ oder „unauthorized“ fehl

Wenn Git-Befehle über HTTPS ausgeführt werden, wird eine Fehlermeldung „permission denied“ oder „unauthorized“ angezeigt.

Dieses Problem tritt auf, wenn eines der folgenden Ereignisse eintritt:

  • In der globalen Git-Konfigurationsdatei fehlt der Authentifizierungshelfer für Secure Source Manager.
  • Der integrierte Anmeldedatenspeicher von Git wird verwendet, anstatt den Authentifizierungshelfer für Secure Source Manager aufzurufen, um neue Anmeldedaten zu erhalten.
  • Ein Systemanmeldedatenhelfer wird verwendet, anstatt den Authentifizierungshelfer für Secure Source Manager aufzurufen, um neue Anmeldedaten zu erhalten.
  • Beim Interagieren mit Secure Source Manager-Repositorys über HTTPS wird eine ältere Version der Google Cloud CLI verwendet. Für Secure Source Manager ist die Google Cloud CLI-Version 395.0.0 oder höher erforderlich.

So beheben Sie dieses Problem:

  1. Führen Sie den folgenden Befehl aus, um den Inhalt Ihrer globalen Git-Konfiguration zu ermitteln.

    git config --list | grep credential

  2. Wenn Sie unter macOS eine Zeile wie *credential*.helper=store oder unter Windows eine Zeile wie credential.helper = manager sehen, entfernen Sie diese Zeilen und authentifizieren Sie sich dann mit gcloud auth login neu, bevor Sie den Git-Befehl noch einmal ausführen.

  3. Wenn die Antwort unter macOS oder Linux nicht credential.https://*.*.sourcemanager.dev.helper=gcloud.sh oder unter Windows nicht credential.https://*.*.sourcemanager.dev.helper=gcloud.cmd enthält, fügen Sie den Authentifizierungshelfer für Secure Source Manager Ihrer globalen Git-Konfiguration hinzu:

    Linux

    1. Führen Sie den folgenden Befehl aus, um den Authentifizierungshelfer für Secure Source Manager Ihrer globalen Git-Konfiguration hinzuzufügen:

      git config --global credential.'https://*.*.sourcemanager.dev'.helper gcloud.sh

    2. Prüfen Sie mit dem folgenden Befehl, ob die Zeile des Authentifizierungshelfers Ihrer globalen Git-Konfiguration hinzugefügt wurde:

      git config --list | grep credential

      Die Ausgabe sollte credential.https://*.*.sourcemanager.dev.helper=gcloud.sh enthalten.

    3. Authentifizieren Sie sich mit gcloud auth login.

    4. Führen Sie einen Git-Befehl aus, um die Authentifizierung zu testen.

    Windows

    1. Prüfen Sie Ihre gcloud CLI-Version anhand der Installationsanleitung für Git und die Google Cloud CLI.

    2. Führen Sie den folgenden Befehl aus, um den Authentifizierungshelfer für Secure Source Manager Ihrer globalen Git-Konfiguration hinzuzufügen:

      git config --global credential.https://*.*.sourcemanager.dev.helper gcloud.cmd

    3. Prüfen Sie mit dem folgenden Befehl, ob die Zeile des Authentifizierungshelfers Ihrer globalen Git-Konfiguration hinzugefügt wurde:

      git config --list | grep credential

      Die Ausgabe sollte credential.https://*.*.sourcemanager.dev.helper=gcloud.cmd enthalten.

    4. Authentifizieren Sie sich mit gcloud auth login.

    5. Führen Sie einen Git-Befehl aus, um die Authentifizierung zu testen.

  4. Wenn Sie die Anmeldedaten für Ihren Git-Host zuvor auf gcloud.sh festgelegt haben, aber eine Fehlermeldung wie 'credential-gcloud.sh' is not a git command erhalten, kann Git das Skript git-credential-gcloud.sh nicht im PATH für Ihren Computer finden. Aktualisieren Sie Ihren PATH oder ersetzen Sie gcloud.sh in Ihrer gitconfig-Datei durch den absoluten Pfad.

Git-HTTPS-Anfragen schlagen mit dem Fehler „invalid token“ fehl

Für Git-HTTPS-Vorgänge ist ein gültiges OAuth-Token als Passwort erforderlich. Dies wird normalerweise vom Git-Anmeldedatenhelfer verarbeitet, funktioniert aber auch mit OAuth-Tokens, die mit anderen Methoden generiert wurden (z. B. Standardanmeldedaten für Anwendungen).

Wenn eine Git-Anfrage aufgrund eines ungültigen Tokens abgelehnt wird, bedeutet das normalerweise, dass Nutzerinformationen nicht aus dem eingehenden Token extrahiert werden konnten. Es gibt mehrere mögliche Ursachen für diesen Fehler:

  • Ihre gcloud CLI-Anmeldung ist möglicherweise abgelaufen.

    Melden Sie sich mit gcloud auth login noch einmal an.

  • Ihr Token hat nicht den erforderlichen Bereich. OAuth-Tokens müssen die folgenden Bereiche haben:

    • https://www.googleapis.com/auth/cloud-platform
    • https://www.googleapis.com/auth/userinfo.email

    Sie können den Tokenbereich mit curl https://oauth2.googleapis.com/tokeninfo?access_token=${TOKEN} prüfen.

  • Sie verwenden ein Token, das aus der GKE-Flotten-Workload Identity generiert wurde:

  • Sie haben Organisationsrichtlinien, die die Verwendung von Tokens außerhalb bestimmter Perimeter verhindern, z. B. kontextsensitiver Zugriff.

    Setzen Sie die gcloud CLI-Konfigurationseigenschaft git_helper_use_adc auf true und aktualisieren Sie Ihre Standardanmeldedaten für Anwendungen, um dieses Problem zu beheben:

    1. Legen Sie die Eigenschaft git_helper_use_adc fest:

      gcloud config set auth/git_helper_use_adc true

    2. Aktualisieren Sie Ihre Standardanmeldedaten für Anwendungen:

      gcloud auth login --update-adc

Git-HTTPS-Anfragen schlagen unter macOS mit dem Fehler 403 aufgrund veralteter Anmeldedaten fehl

Wenn Sie Git-Vorgänge über HTTPS unter macOS ausführen, wird möglicherweise der Fehler 403 angezeigt.

Dieses Problem kann unter macOS auftreten, wenn Sie den iCloud-Schlüsselbund verwenden, der die gcloud CLI-Authentifizierungstokens beeinträchtigen kann, indem er veraltete Tokens speichert und synchronisiert. Diese veralteten Tokens können dazu führen, dass die Authentifizierung mit Secure Source Manager fehlschlägt, auch nachdem Sie sich mit gcloud auth login neu authentifiziert haben.

Löschen Sie alle veralteten Anmeldedaten manuell aus der Schlüsselbundverwaltung, um dieses Problem zu beheben:

  1. Öffnen Sie auf Ihrem Mac die Anwendung Schlüsselbundverwaltung (unter /Applications/Utilities/).
  2. Suchen Sie nach sourcemanager.dev.
  3. Löschen Sie alle Einträge vom Typ „Internetpasswort“, die mit *.*.sourcemanager.dev oder der URL Ihrer Secure Source Manager-Instanz übereinstimmen. Klicken Sie dazu mit der rechten Maustaste auf den Eintrag und wählen Sie Löschen aus.
  4. Versuchen Sie nach dem Löschen der Einträge noch einmal, den Git-Vorgang auszuführen. Möglicherweise werden Sie aufgefordert, sich mit der gcloud CLI neu zu authentifizieren. Wenn Git-Vorgänge weiterhin fehlschlagen, führen Sie gcloud auth login aus, bevor Sie es noch einmal versuchen.

SSM gibt einen Fehler zurück, wenn KSA-Tokens (Kubernetes Service Account) mit der GKE-Flotten-Workload Identity verwendet werden

Wenn Sie die GKE-Flotten-Workload Identity verwenden, werden Roh-KSA-Tokens von Secure Source Manager nicht unterstützt. Die Verwendung dieser Tokens führt zu einem Fehler.

Um dieses Problem zu beheben, müssen Sie die Identität eines Dienstkontos annehmen und die Arbeitslast an ein Google-Dienstkonto binden. Außerdem müssen Sie Ihrer KSA-Konfiguration die folgende Annotation hinzufügen:

iam.gke.io/gcp-service-account: SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com

Projekt wird in der Produktauswahl der Web-UI nicht angezeigt

Wenn Sie die Produktauswahl der Web-UI von Secure Source Manager verwenden, wird Ihr Projekt nicht angezeigt.

Dieses Problem tritt auf, wenn Sie mehrere Anmeldedaten für Secure Source Manager haben.

So beheben Sie dieses Problem:

  • Löschen Sie Ihre Cookies, indem Sie der URL Ihrer Secure Source Manager-Instanz Folgendes anhängen: /_oauth/consent

    Wenn Ihre Instanz-URL beispielsweise https://my-instance-098765432123.us-central1.sourcemanager.dev/ lautet, geben Sie https://my-instance-098765432123.us-central1.sourcemanager.dev/_oauth/consent in die Adressleiste Ihres Browsers ein und melden Sie sich dann mit den richtigen Anmeldedaten an.

Die Datei „triggers“ löst keine Builds aus

Wenn Builds nach dem Senden Ihrer Datei „triggers“ nicht wie erwartet ausgelöst werden, liegt möglicherweise eines der folgenden Probleme vor:

  • Die Datei „triggers“ befindet sich nicht im Standardzweig. Verschieben Sie die Datei „triggers“ in den Standardzweig, um dieses Problem zu beheben.
  • Die Datei „triggers“ hat ein ungültiges Format. Dieser Fehler wird durch ein Banner auf der Repository-Seite mit der Meldung Build triggers configuration error: ... angezeigt. Informationen zum Beheben dieses Fehlers finden Sie unter Schema der Datei „triggers“. Wenn die Konfiguration der Datei „triggers“ korrekt ist, wird im Banner auf der Repository-Seite Valid build triggers configuration angezeigt.

Konfigurationsfehler bei Build-Triggern

Nachdem Sie die Datei triggers.yaml an Ihr Secure Source Manager-Repository gesendet haben, wird im Banner der folgende Fehler angezeigt:

Build cannot be created.

Dieses Problem tritt aus folgenden Gründen auf:

  • Die Cloud Build-Konfigurationsdatei enthält ungültige Optionen.
  • Die Cloud Build-Konfigurationsdatei hat ein ungültiges Format.
  • Das Secure Source Manager-Dienstkonto hat nicht die erforderlichen Berechtigungen, um das vom Nutzer angegebene Cloud Build-Dienstkonto zu verwenden.

So beheben Sie dieses Problem:

Build schlägt während der Ausführung fehl

Wenn ein Build erfolgreich ausgelöst wird, aber während der Ausführung fehlschlägt, hat der zugehörige Commit den Commit-Status „Fehler“.

Klicken Sie auf der Repository-Seite neben dem Commit-Status „Fehler“ auf Details , um Fehler bei einem Build zu beheben.

Das Cloud Build-Ausführungsprotokoll wird geöffnet. Weitere Informationen zur Fehlerbehebung bei Builds in Cloud Build finden Sie unter Fehler bei Builds beheben.

Tageskontingent wird nach dem Neuerstellen nicht zurückgesetzt

Wenn Sie eine Secure Source Manager-Instanz löschen und am selben Tag mit derselben Instanz-ID neu erstellen, wird möglicherweise ein Fehler angezeigt, dass das Kontingent erschöpft oder das Limit erreicht ist.

Dieses Problem tritt auf, weil das Kontingent für die Anmeldedatenprüfung ein tägliches Ratenkontingent ist, das mit der Instanz-ID verknüpft ist. Wenn Sie eine Instanz mit derselben ID am selben Tag löschen und neu erstellen, wird die Kontingentnutzung nicht zurückgesetzt.

Sie haben folgende Möglichkeiten, dieses Problem zu beheben:

  • Warten Sie bis zum nächsten Tag, damit die tägliche Kontingentnutzung automatisch auf 0 zurückgesetzt wird.
  • Erstellen Sie die Instanz mit einer anderen, eindeutigen Instanz-ID neu.
  • Überspringen Sie die Anmeldedatenprüfung vorübergehend oder fordern Sie eine Kontingenterhöhung an. Weitere Informationen finden Sie unter Verfügbares Kontingent erhöhen.