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 ist in Ihrem Projekt nicht aktiviert.
  • Sie haben in Ihrem Projekt nicht die Rolle „Repo Admin“ oder die Berechtigungen zum Erstellen von Repositories in der Secure Source Manager-Instanz.

So lösen Sie dieses Problem:

  • Aktivieren Sie die Secure Source Manager API in Ihrem Projekt.
  • Bitten Sie Ihren Administrator, Ihnen die folgenden Rollen zuzuweisen:
    • Rolle „Repo-Administrator“ (roles/securesourcemanager.repoAdmin) für Ihr Projekt.
    • Auf die Secure Source Manager-Instanz zugreifende Person (roles/securesourcemanager.instanceAccessor).
    • „Instance Repository Creator“ (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 wurde mit Homebrew oder einer anderen nicht standardmäßigen Installation installiert.
  • git-credential-gcloud.sh wurde nicht zu Ihrem PATH hinzugefügt.

So lösen 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 versuchen, Git-Vorgänge über SSH auszufü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 „Zugriff verweigert“ oder „Nicht autorisiert“ fehl

Wenn Git-Befehle über HTTPS ausgeführt werden, wird eine Fehlermeldung „Zugriff verweigert“ oder „Nicht autorisiert“ angezeigt.

Dieses Problem tritt auf, wenn einer der folgenden Fälle eintritt:

  • In der globalen Git-Konfigurationsdatei fehlt der Authentifizierungs-Helper für Secure Source Manager.
  • Der integrierte Anmeldedatenspeicher von Git wird verwendet, anstatt den Authentifizierungs-Helper von Secure Source Manager aufzurufen, um neue Anmeldedaten abzurufen.
  • Es wird ein System-Credential Helper verwendet, anstatt den Secure Source Manager-Authentifizierungs-Helper aufzurufen, um ein neues Credential zu erhalten.
  • Beim Interagieren mit Secure Source Manager-Repositories ü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 lösen 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 auf macOS eine Zeile sehen, die *credential*.helper=store ähnelt, oder auf Windows eine Zeile, die credential.helper = manager ähnelt, entfernen Sie diese Zeilen und authentifizieren Sie sich dann noch einmal mit gcloud auth login, bevor Sie den Git-Befehl noch einmal ausführen.

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

    Linux

    1. Führen Sie den folgenden Befehl aus, um den Authentifizierungs-Helper von Secure Source Manager zu 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 für den Authentifizierungshelfer zu 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, indem Sie gcloud auth login ausführen.

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

    Windows

    1. Prüfen Sie die Version der gcloud CLI anhand der Anleitung unter Git und Google Cloud CLI installieren.

    2. Führen Sie den folgenden Befehl aus, um den Authentifizierungs-Helper von Secure Source Manager zu 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 für den Authentifizierungshelfer zu 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, indem Sie gcloud auth login ausführen.

    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, bedeutet das, dass Git das git-credential-gcloud.sh-Skript im PATH für Ihren Computer nicht finden kann. Aktualisieren Sie PATH oder ersetzen Sie gcloud.sh in Ihrer gitconfig-Datei durch den absoluten Pfad.

Git-HTTPS-Anfragen schlagen mit ungültigem Token fehl

Für Git-HTTPS-Vorgänge ist ein gültiges OAuth-Token als Passwort erforderlich. Dies wird normalerweise vom Git-Anmeldedaten-Helper übernommen, 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. Dafür gibt es mehrere mögliche Ursachen:

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

    Melde dich wieder mit gcloud auth login 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 prüfen, indem Sie curl https://oauth2.googleapis.com/tokeninfo?access_token=${TOKEN} aufrufen.

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

    Um dieses Problem zu beheben, legen Sie die git_helper_use_adc-Konfigurationseigenschaft der gcloud CLI auf true fest und aktualisieren Sie Ihre Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC):

    1. Legen Sie das Attribut git_helper_use_adc fest:

      gcloud config set auth/git_helper_use_adc true

    2. ADC aktualisieren:

      gcloud auth login --update-adc

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

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

Dieses Problem kann unter macOS auftreten, wenn Sie den iCloud-Schlüsselbund verwenden. Dieser kann die Authentifizierungstokens der gcloud CLI beeinträchtigen, indem er alte Tokens speichert und synchronisiert. Diese abgelaufenen 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.

Um dieses Problem zu beheben, löschen Sie alle veralteten Anmeldedaten manuell aus dem Schlüsselbund:

  1. Öffnen Sie auf Ihrem Mac die Schlüsselbundverwaltung (im Ordner /Applications/Utilities/).
  2. Suchen Sie nach sourcemanager.dev.
  3. Löschen Sie alle Einträge vom Typ „Internetkennwort“, 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 noch einmal mit der gcloud CLI 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-Identität verwendet werden

Wenn Sie die GKE-Flotten-Workload Identity verwenden, werden rohe 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 Anmerkung hinzufügen:

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

Projekt wird nicht in der Produktauswahl der Weboberfläche angezeigt

Wenn Sie die Produktauswahl der Secure Source Manager-Weboberfläche verwenden, wird Ihr Projekt nicht angezeigt.

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

So lösen Sie dieses Problem:

  • Löschen Sie Ihre Cookies, indem Sie die folgende URL an die URL Ihrer Secure Source Manager-Instanz 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 Triggerdatei löst keine Builds aus

Wenn Builds nach dem Einreichen der Triggerdatei nicht wie erwartet ausgelöst werden, liegt möglicherweise eines der folgenden Probleme vor:

  • Die Datei mit den Triggern befindet sich nicht im Standard-Branch. Um dieses Problem zu beheben, verschieben Sie die Datei mit den Triggern in Ihren Standardbranch.
  • Die Datei mit den Triggern hat ein ungültiges Format. Dieser Fehler wird durch ein Banner auf der Repository-Seite mit dem Text Build triggers configuration error: ... angezeigt. Informationen zum Beheben des Problems finden Sie unter Schema der Triggerdatei. Wenn die Konfiguration der Triggerdatei korrekt ist, wird auf der Repository-Seite das Banner Valid build triggers configuration angezeigt.

Konfigurationsfehler bei Build-Triggern

Nachdem Sie Ihre triggers.yaml-Datei in Ihr Secure Source Manager-Repository hochgeladen haben, wird der folgende Fehler in einem Banner angezeigt:

Build cannot be created.

Dieses Problem kann folgende Ursachen haben:

  • Die Cloud Build-Konfigurationsdatei enthält 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 nutzerverwaltete Dienstkonto des Repositorys.
  • Das nutzerverwaltete Dienstkonto hat nicht die Rolle Dienstkontonutzer für das Cloud Build-Dienstkonto.
  • Das nutzerverwaltete Dienstkonto hat nicht die Rolle Cloud Build Editor 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 Triggerdatei verwenden.
  • Prüfen Sie, ob alle erforderlichen Rollen gewährt wurden. Weitere Informationen finden Sie unter Erforderliche Dienstkontorollen.
  • Wenn Sie ein vom Nutzer verwaltetes Dienstkonto in einem anderen Projekt verwenden, prüfen Sie, ob die Organisationsrichtlinie iam.disableCrossProjectServiceAccountUsage in dem Projekt, in dem das Dienstkonto gehostet wird, deaktiviert ist.

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

Wenn Sie ein fehlgeschlagenes Build beheben möchten, klicken Sie auf der Repository-Seite neben dem fehlgeschlagenen Commit-Status auf Details.

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

Git-Push aufgrund erkannter sensibler Daten abgelehnt

Wenn Sie Commits in ein Repository mit aktivierter Geheimnisüberprüfung pushen, schlägt der Push mit einer Fehlermeldung ähnlich der folgenden fehl:

remote: Push rejected: Sensitive data detected.

Dieses Problem tritt auf, wenn beim Secret-Scanning oder mit einer benutzerdefinierten Inspektionsvorlage vertrauliche Informationen in Ihrem Commit-Verlauf erkannt werden.

So lösen Sie dieses Problem:

  • Machen Sie den problematischen Commit mit git reset --soft rückgängig und entfernen Sie die vertraulichen Informationen, bevor Sie den Commit noch einmal ausführen.

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

    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 sie noch am selben Tag mit derselben Instanz-ID neu erstellen, erhalten Sie möglicherweise eine Fehlermeldung, dass das Kontingent für die Geheimnisüberprüfung erschöpft oder das Limit erreicht ist.

Dieses Problem tritt auf, weil das Kontingent für die Geheimnisüberprü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 das tägliche Kontingent am zweiten Tag automatisch auf 0 zurückgesetzt wird.
  • Erstellen Sie die Instanz mit einer anderen, eindeutigen Instanz-ID neu.
  • Überspringen Sie die Geheimnisprüfung vorübergehend oder fordern Sie eine Kontingenterhöhung an. Weitere Informationen finden Sie unter Verfügbares Kontingent erhöhen.

Fehler beim Konfigurieren des Repository-Dienstkontos

Der folgende Fehler wird angezeigt, wenn Sie versuchen, ein Repository mit einem nutzerverwalteten 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 dem Repository zuordnen möchten. Secure Source Manager prüft, ob Sie berechtigt sind, als Dienstkonto zu agieren, bevor Sie es dem Repository zuordnen dürfen.

Bitten Sie Ihren Administrator, Ihnen die Rolle „Dienstkontonutzer“ für das Dienstkonto zuzuweisen.