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 das 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 das 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 versuchen, Git-Vorgänge über SSH auszuführen, erhalten Sie möglicherweise eine der folgenden Fehlermeldungen:

  • 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 Secure Source Manager-Authentifizierungshelfer.
  • Der integrierte Anmeldedatenspeicher von Git wird verwendet, anstatt den Secure Source Manager-Authentifizierungshelfer aufzurufen, um neue Anmeldedaten zu erhalten.
  • Ein Systemanmeldedatenhelfer wird verwendet, anstatt den Secure Source Manager-Authentifizierungshelfer 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 das 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 Secure Source Manager-Authentifizierungshelfer Ihrer globalen Git-Konfiguration hinzu:

    Linux

    1. Führen Sie den folgenden Befehl aus, um den Secure Source Manager-Authentifizierungshelfer 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 Anleitung unter Git und die Google Cloud CLI installieren.

    2. Führen Sie den folgenden Befehl aus, um den Secure Source Manager-Authentifizierungshelfer 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, kann aber auch mit OAuth-Tokens funktionieren, 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. Melden Sie sich mit „application-default“ an:

      gcloud auth application-default login

    2. Legen Sie die Eigenschaft git_helper_use_adc fest:

      gcloud config set auth/git_helper_use_adc true

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, erhalten Sie möglicherweise den Fehler 403.

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 „Internet-Passwort“, 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 mit der GKE-Flotten-Workload Identity verwendet werden

Bei Verwendung der GKE-Flotten-Workload Identity, 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 das 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 nach dem Senden der Datei „triggers“ keine Builds 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 des Problems 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.

Fehler bei der Konfiguration von 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 hat ungültige Optionen oder ein ungültiges Format.
  • Der Secure Source Manager-Dienst-Agent hat nicht die Rolle Ersteller von Dienstkonto-Tokens für das vom Nutzer verwaltete Dienstkonto des Repositorys.
  • Das vom Nutzer verwaltete Dienstkonto hat nicht die Rolle Dienstkontonutzer für das Cloud Build-Dienstkonto.
  • Das vom Nutzer verwaltete Dienstkonto hat nicht die Rolle Cloud Build-Bearbeiter für das Projekt, in dem die Builds ausgeführt werden.
  • Die Organisationsrichtlinie iam.disableCrossProjectServiceAccountUsage blockiert die Verwendung des vom Nutzer verwalteten Dienstkontos (wenn sich das Dienstkonto in einem anderen Projekt befindet).

So beheben Sie das Problem:

  • Achten Sie darauf, dass Sie das richtige Schema für die Datei „triggers“ verwenden.
  • Prüfen Sie, ob alle erforderlichen Rollen gewährt wurden. Weitere Informationen finden Sie unter Erforderliche Dienst kontorollen.
  • Wenn Sie ein vom Nutzer verwaltetes Dienstkonto in einem anderen Projekt verwenden, prüfen Sie, ob die Organisationsrichtlinie iam.disableCrossProjectServiceAccountUsage in dem Projekt deaktiviert ist, in dem das Dienstkonto gehostet wird.

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.

Git-Push aufgrund erkannter sensibler Daten abgelehnt

Wenn Sie Commits in ein Repository mit aktivierter Secret-Suche pushen, schlägt der Push mit einer Fehlermeldung ähnlich der folgenden fehl:

remote: Push rejected: Sensitive data detected.

Dieses Problem tritt auf, wenn bei der Secret-Suche oder mit einer benutzerdefinierten Überprüfungsvorlage sensible Informationen in Ihrem Commit-Verlauf gefunden werden.

So beheben Sie das Problem:

  • Setzen Sie den problematischen Commit mit git reset --soft zurück und entfernen Sie die sensiblen Informationen, bevor Sie noch einmal committen.

  • Wenn die erkannten Informationen akzeptabel sind und Sie die entsprechenden Berechtigungen haben, umgehen Sie die Überprüfung mit der Push-Option -o dlpskip=true:

    git push -o dlpskip=true origin BRANCH_NAME

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, erhalten Sie möglicherweise einen Fehler, dass das Kontingent erschöpft oder das Limit für die Secret-Suche erreicht ist.

Dieses Problem tritt auf, weil das Kontingent für die Secret-Suche ein tägliches Ratenkontingent ist, das mit der Instanz-ID verknüpft ist. Wenn Sie eine Instanz am selben Tag mit derselben ID 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 Secret-Suche vorübergehend oder fordern Sie eine Kontingenterhöhung an. Weitere Informationen finden Sie unter Verfügbares Kontingent erhöhen.

Fehler beim Konfigurieren des Dienstkontos für das Repository

Der folgende Fehler wird angezeigt, wenn Sie versuchen, ein Repository mit einem vom Nutzer verwalteten Dienstkonto zu erstellen oder zu aktualisieren:

Permission denied on resource ...

Dieses Problem tritt auf, wenn Sie nicht die Rolle Dienstkontonutzer (roles/iam.serviceAccountUser) für das Dienstkonto haben, das Sie mit dem Repository verknüpfen möchten. Secure Source Manager prüft, ob Sie berechtigt sind, als Dienstkonto zu agieren, bevor Sie es mit dem Repository verknüpfen können.

Bitten Sie Ihren Administrator, Ihnen die Rolle „Dienstkontonutzer“ für das Dienstkonto zu gewähren, um dieses Problem zu beheben.