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 in folgenden Fällen auf:

  • Die Secure Source Manager API ist in Ihrem Projekt nicht aktiviert.
  • Sie haben nicht die Rolle „Repo Admin“ für Ihr Projekt 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.
    • Instance Accessor (roles/securesourcemanager.instanceAccessor) für die Secure Source Manager-Instanz.
    • Instance Repository Creator (roles/securesourcemanager.instanceRepositoryCreator) für die Secure Source Manager-Instanz.

Weitere Einzelheiten 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 in folgenden Fällen auf:

  • Die gcloud CLI wurde mit Homebrew oder einer anderen nicht standardmäßigen Installation installiert.
  • git-credential-gcloud.sh wird 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 sich git-credential-gcloud.sh in Ihrem Pfad befindet:

    which git-credential-gcloud.sh

SSH-Verbindung schlägt mit dem Fehler „Keine Übereinstimmung“ fehl

Wenn Sie Git-Vorgänge über SSH ausfü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 erforderlichen kryptografischen Algorithmen nicht unterstützt. Dies kann passieren, wenn Sie einen älteren SSH-Client verwenden oder wenn Ihr Client nicht für die Verwendung unterstützter Algorithmen konfiguriert ist.

Secure Source Manager erfordert einen der folgenden Algorithmen:

  • Algorithmen für den Schlüsselaustausch: curve25519-sha256, diffie-hellman-group14-sha256
  • Chiffren: 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 „Berechtigung verweigert“ oder „Nicht autorisiert“ fehl

Wenn Git-Befehle über HTTPS ausgeführt werden, wird eine Fehlermeldung angezeigt, dass die Berechtigung verweigert wurde oder nicht autorisiert ist.

Dieses Problem tritt in den folgenden Fällen auf:

  • In der globalen Git-Konfigurationsdatei fehlt der Secure Source Manager-Authentifizierungs-Helper.
  • 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 neue Anmeldedaten abzurufen.
  • Bei der Interaktion mit Secure Source Manager-Repositories über HTTPS wird eine ältere Version der Google Cloud CLI verwendet. Secure Source Manager erfordert die Google Cloud CLI-Version 395.0.0 oder höher.

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 unter macOS eine Zeile wie *credential*.helper=store oder unter Windows OS eine Zeile wie credential.helper = manager sehen, 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 nicht credential.https://*.*.sourcemanager.dev.helper=gcloud.sh unter macOS oder Linux oder credential.https://*.*.sourcemanager.dev.helper=gcloud.cmd unter Windows enthält, fügen Sie den Secure Source Manager-Authentifizierungs-Helper zu Ihrer globalen Git-Konfiguration hinzu:

    Linux

    1. Führen Sie den folgenden Befehl aus, um den Secure Source Manager-Authentifizierungs-Helper 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 Authentifizierungs-Helper 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 über gcloud auth login.

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

    Windows

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

    2. Führen Sie den folgenden Befehl aus, um den Secure Source Manager-Authentifizierungs-Helper 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 Authentifizierungs-Helper 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 über 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 einen Fehler 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 Ihre PATH oder ersetzen Sie die 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 Ansätzen generiert wurden (z. B. Standardanmeldedaten für Anwendungen).

Wenn eine Git-Anfrage aufgrund eines ungültigen Tokens abgelehnt wird, bedeutet das normalerweise, dass keine Nutzerinformationen 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.

    Melde dich dann über gcloud auth login an.

  • Ihr Token hat keinen ausreichenden 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 durch Aufrufen von curl https://oauth2.googleapis.com/tokeninfo?access_token=${TOKEN} prüfen.

  • Sie verwenden ein Token, das von der Workload Identity der GKE-Flotte generiert wurde:

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

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

    1. Melden Sie sich mit den Standardanmeldedaten für Anwendungen an:

      gcloud auth application-default login

    2. Legen Sie das Attribut 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 einen 403-Fehler.

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

Löschen Sie alle veralteten Anmeldedaten manuell aus dem Schlüsselbund, 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 „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 Kubernetes-Dienstkontotokens (KSA) mit der GKE-Flotten-Workload Identity 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 übernehmen 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.

Projekt wird in der Produktauswahl der Weboberfläche nicht 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 Folgendes 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.

Triggerdatei löst keine Builds aus

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

  • Die Triggerdatei befindet sich nicht im Standardzweig. Verschieben Sie die Triggerdatei in den Standardzweig, um dieses Problem zu beheben.
  • Die Triggerdatei hat ein ungültiges Format. Dieser Fehler wird auf der Repository-Seite durch ein Banner mit der Meldung Build triggers configuration error: ... angezeigt. Informationen zum Beheben dieses Problems finden Sie im Schema für Triggerdateien. Wenn die Konfiguration der Triggerdatei 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 der folgende Fehler in einem Banner angezeigt:

Build cannot be created.

Das Problem kann folgende Ursachen haben:

  • 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 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-Bearbeiter für das Projekt, in dem Builds ausgeführt werden.
  • Die Organisationsrichtlinie iam.disableCrossProjectServiceAccountUsage blockiert die Verwendung des nutzerverwalteten 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 zugewiesen sind. Weitere Informationen finden Sie unter Erforderliche Dienstkontorollen.
  • Wenn Sie ein nutzerverwaltetes 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 einen fehlgeschlagenen Build beheben möchten, klicken Sie auf der Repository-Seite neben dem Status des fehlgeschlagenen Commits 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 aktiviertem Secret-Scanning übertragen, schlägt der Push mit einer Fehlermeldung wie der folgenden fehl:

remote: Push rejected: Sensitive data detected.

Dieses Problem tritt auf, wenn beim Secret-Scanning oder durch eine benutzerdefinierte 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 Neuerstellung 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 eine Fehlermeldung, dass das Kontingent erschöpft oder das Limit erreicht ist.

Dieses Problem tritt auf, weil das Kontingent für das Scannen von Secrets 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 zweiten Tag, bis die tägliche Kontingentnutzung automatisch auf 0 zurückgesetzt wird.
  • Erstellen Sie die Instanz mit einer anderen, eindeutigen Instanz-ID neu.
  • Überspringen Sie das Secret-Scanning 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 die Rolle Dienstkontonutzer (roles/iam.serviceAccountUser) für das Dienstkonto, das Sie mit dem Repository verknüpfen möchten, nicht haben. 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 „Service Account User“ für das Dienstkonto zuzuweisen, um dieses Problem zu beheben.