Dépannage

Cette page vous explique comment résoudre les problèmes liés à Secure Source Manager.

Message d'erreur lors de la création d'un dépôt

L'erreur suivante s'affiche lorsque vous essayez de créer un dépôt :

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

Ce problème se produit dans les cas suivants :

  • L'API Secure Source Manager n'est pas activée dans votre projet.
  • Vous ne disposez pas du rôle Administrateur de dépôt dans votre projet ni des autorisations nécessaires pour créer des dépôts dans l'instance Secure Source Manager.

Pour résoudre ce problème :

  • Activez l'API Secure Source Manager dans votre projet.
  • Demandez à votre administrateur de vous attribuer les rôles suivants :
    • Rôle Administrateur de dépôt (roles/securesourcemanager.repoAdmin) dans votre projet.
    • Accesseur d'instances (roles/securesourcemanager.instanceAccessor) dans l'instance Secure Source Manager.
    • Créateur de dépôts d'instances (roles/securesourcemanager.instanceRepositoryCreator) dans l'instance Secure Source Manager.

Pour en savoir plus, consultez la page Contrôle des accès avec IAM.

Message d'erreur lors du clonage d'un dépôt sur un Mac

L'erreur suivante s'affiche lorsque vous essayez de cloner un dépôt :

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

Ce problème se produit dans les cas suivants :

  • gcloud CLI est installé à l'aide de Homebrew ou d'une autre installation non standard.
  • git-credential-gcloud.sh n'est pas ajouté à votre PATH.

Pour résoudre ce problème :

  • Exécutez source $HOMEBREW_PREFIX/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/path.zsh.inc.

  • Vérifiez que git-credential-gcloud.sh se trouve dans votre chemin d'accès en exécutant la commande suivante :

    which git-credential-gcloud.sh

Échec de la connexion SSH avec l'erreur "no matching"

Lorsque vous tentez d'effectuer des opérations Git via SSH, vous pouvez recevoir l'un des messages d'erreur suivants :

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

Ce problème se produit lorsque votre client SSH ne prend pas en charge les algorithmes de chiffrement requis par Secure Source Manager. Cela peut se produire si vous utilisez un client SSH plus ancien ou si votre client n'est pas configuré pour utiliser des algorithmes compatibles.

Secure Source Manager nécessite l'un des algorithmes suivants :

  • Algorithmes d'échange de clés : curve25519-sha256, diffie-hellman-group14-sha256
  • Chiffrements : chacha20-poly1305@openssh.com, aes128-ctr, aes192-ctr, aes256-ctr, aes128-gcm@openssh.com, aes256-gcm@openssh.com
  • MAC : hmac-sha2-256-etm@openssh.com, hmac-sha2-256

Pour résoudre ce problème, mettez à jour votre client SSH vers une version récente qui prend en charge ces algorithmes.

Échec des requêtes Git HTTPS avec l'erreur "permission denied" ou "unauthorized"

Lorsque des commandes Git sont tentées via HTTPS, un message d'erreur "permission denied" ou "unauthorized" s'affiche.

Ce problème se produit dans l'un des cas suivants :

  • Le fichier de configuration Git global ne contient pas l'outil d'authentification Secure Source Manager.
  • Le magasin d'identifiants intégré de Git est utilisé au lieu d'appeler l'outil d'authentification Secure Source Manager pour obtenir un nouvel identifiant.
  • Un outil d'identifiants système est utilisé au lieu d'appeler l'outil d'authentification Secure Source Manager pour obtenir un nouvel identifiant.
  • Une ancienne version de Google Cloud CLI est utilisée lors de l'interaction avec les dépôts Secure Source Manager via HTTPS. Secure Source Manager nécessite Google Cloud CLI version 395.0.0 ou ultérieure.

Pour résoudre ce problème :

  1. Exécutez la commande suivante pour déterminer le contenu de votre configuration Git globale.

    git config --list | grep credential

  2. Si vous voyez une ligne semblable à *credential*.helper=store sur macOS ou credential.helper = manager sur Windows, supprimez ces lignes, puis réauthentifiez-vous à l'aide de gcloud auth login avant de réessayer la commande Git.

  3. Si la réponse n'inclut pas credential.https://*.*.sourcemanager.dev.helper=gcloud.sh sur macOS ou Linux, ou credential.https://*.*.sourcemanager.dev.helper=gcloud.cmd sur Windows, ajoutez l'outil d'authentification Secure Source Manager à votre configuration Git globale :

    Linux

    1. Pour ajouter l'outil d'authentification Secure Source Manager à votre configuration Git globale, exécutez la commande suivante :

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

    2. Vérifiez que la ligne de l'outil d'authentification est ajoutée à votre configuration Git globale en exécutant la commande suivante :

      git config --list | grep credential

      La sortie doit inclure credential.https://*.*.sourcemanager.dev.helper=gcloud.sh.

    3. Authentifiez-vous en exécutant gcloud auth login.

    4. Exécutez une commande Git pour tester l'authentification.

    Windows

    1. Vérifiez votre version de gcloud CLI en suivant les instructions Installer Git et Google Cloud CLI.

    2. Pour ajouter l'outil d'authentification Secure Source Manager à votre configuration Git globale, exécutez la commande suivante :

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

    3. Vérifiez que la ligne de l'outil d'authentification est ajoutée à votre configuration Git globale en exécutant la commande suivante :

      git config --list | grep credential

      La sortie doit inclure credential.https://*.*.sourcemanager.dev.helper=gcloud.cmd.

    4. Authentifiez-vous en exécutant gcloud auth login.

    5. Exécutez une commande Git pour tester l'authentification.

  4. Si vous avez précédemment défini l'identifiant de votre hôte Git sur gcloud.sh, mais que vous obtenez une erreur telle que 'credential-gcloud.sh' is not a git command, cela indique que Git ne parvient pas à trouver le script git-credential-gcloud.sh dans le PATH de votre machine. Mettez à jour votre PATH ou remplacez gcloud.sh dans votre fichier gitconfig par le chemin absolu.

Échec des requêtes Git HTTPS avec un jeton non valide

Un jeton OAuth valide est requis comme mot de passe pour les opérations Git HTTPS. Il est normalement géré par l'outil d'identifiants Git, mais il peut également fonctionner avec des jetons OAuth générés à l'aide d'autres approches (par exemple, les identifiants par défaut de l'application).

Si une requête Git est rejetée en raison d'un jeton non valide, cela signifie normalement que les informations utilisateur n'ont pas pu être extraites du jeton entrant. Plusieurs causes sont possibles :

  • Votre connexion gcloud CLI a peut-être expiré.

    Connectez-vous à nouveau à l'aide de gcloud auth login.

  • Votre jeton ne dispose pas d'un champ d'application suffisant. Les jetons OAuth doivent avoir les champs d'application suivants :

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

    Vous pouvez vérifier le champ d'application du jeton en appelant curl https://oauth2.googleapis.com/tokeninfo?access_token=${TOKEN}.

  • Vous utilisez un jeton généré à partir de l'identité de charge de travail du parc GKE :

  • Vous disposez de règles d'administration qui empêchent l'utilisation de jetons en dehors de certains périmètres, par exemple l'accès contextuel.

    Pour résoudre ce problème, définissez la propriété de configuration gcloud CLI git_helper_use_adc sur true et mettez à jour vos identifiants par défaut de l'application (ADC) :

    1. Définissez la propriété git_helper_use_adc :

      gcloud config set auth/git_helper_use_adc true

    2. Mettez à jour vos ADC :

      gcloud auth login --update-adc

Échec des requêtes Git HTTPS sur macOS avec l'erreur 403 en raison d'identifiants obsolètes

Lorsque vous effectuez des opérations Git via HTTPS sur macOS, vous pouvez recevoir une erreur 403.

Ce problème peut se produire sur macOS si vous utilisez le trousseau iCloud, qui peut interférer avec les jetons d'authentification gcloud CLI en stockant et en synchronisant des jetons obsolètes. Ces jetons obsolètes peuvent entraîner l'échec de l'authentification avec Secure Source Manager, même après vous être réauthentifié à l'aide de gcloud auth login.

Pour résoudre ce problème, supprimez manuellement les identifiants obsolètes du trousseau d'accès :

  1. Ouvrez l'application Trousseau d'accès sur votre Mac (située dans /Applications/Utilities/).
  2. Recherchez sourcemanager.dev.
  3. Supprimez toutes les entrées de type "Mot de passe Internet" qui correspondent à *.*.sourcemanager.dev ou à l'URL de votre instance Secure Source Manager en cliquant avec le bouton droit sur l'entrée et en sélectionnant Supprimer.
  4. Après avoir supprimé les entrées, réessayez votre opération Git. Vous serez peut-être invité à vous réauthentifier avec gcloud CLI. Si les opérations Git continuent d'échouer, exécutez gcloud auth login avant de réessayer.

SSM renvoie une erreur lors de l'utilisation de jetons de compte de service Kubernetes (KSA) avec l'identité de charge de travail du parc GKE

Lorsque vous utilisez l'identité de charge de travail du parc GKE, les jetons KSA bruts ne sont pas compatibles avec Secure Source Manager. L'utilisation de ces jetons entraîne une erreur.

Pour résoudre ce problème, vous devez emprunter l'identité d'un compte de service et lier la charge de travail à un compte de service Google. Vous devez également ajouter l'annotation suivante à votre configuration KSA :

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

Le projet ne s'affiche pas dans le sélecteur de produit de l'interface Web

Lorsque vous utilisez le sélecteur de produit de l'interface Web Secure Source Manager, votre projet n'apparaît pas.

Ce problème se produit lorsque vous disposez de plusieurs identifiants de connexion pour Secure Source Manager.

Pour résoudre ce problème :

  • Effacez vos cookies en ajoutant /_oauth/consent à l'URL de votre instance Secure Source Manager.

    Par exemple, si l'URL de votre instance est https://my-instance-098765432123.us-central1.sourcemanager.dev/, saisissez https://my-instance-098765432123.us-central1.sourcemanager.dev/_oauth/consent dans la barre d'adresse de votre navigateur, puis connectez-vous avec les identifiants appropriés.

Le fichier de déclencheurs ne déclenche pas de compilations

Si les compilations ne sont pas déclenchées comme prévu après l'envoi de votre fichier de déclencheurs, vous pouvez rencontrer l'un des problèmes suivants :

  • Le fichier de déclencheurs ne se trouve pas dans la branche par défaut. Pour résoudre ce problème, déplacez votre fichier de déclencheurs vers votre branche par défaut.
  • Le format du fichier de déclencheurs n'est pas valide. Cette erreur est indiquée par une bannière sur la page du dépôt : Build triggers configuration error: .... Pour résoudre ce problème, consultez le schéma du fichier de déclencheurs. Lorsque la configuration du fichier de déclencheurs est correcte, la bannière sur la page du dépôt indique Valid build triggers configuration.

Erreur de configuration des déclencheurs de compilation

Après avoir envoyé votre fichier triggers.yaml à votre dépôt Secure Source Manager, l'erreur suivante s'affiche dans une bannière :

Build cannot be created.

Ce problème se produit pour les raisons suivantes :

  • Le fichier de configuration Cloud Build comporte des options non valides.
  • Le format du fichier de configuration de compilation Cloud Build n'est pas valide.
  • Le compte de service Secure Source Manager ne dispose pas des autorisations requises pour utiliser le compte de service Cloud Build spécifié par l'utilisateur.

Pour résoudre ce problème :

  • Assurez-vous de suivre le schéma de fichier de déclencheurs approprié Triggers file schema.
  • Assurez-vous que le compte de service Secure Source Manager et le compte de service Cloud Build disposent des autorisations suffisantes. Pour afficher les autorisations requises, consultez la section Rôles de compte de service requis.

Échec de la compilation lors de l'exécution

Si une compilation est déclenchée, mais échoue lors de l'exécution, le commit associé présente l'état d'échec.

Pour résoudre le problème d'une compilation ayant échoué, cliquez sur Détails sur la page du dépôt, à côté de l'état d'échec du commit.

Le journal d'exécution Cloud Build s'ouvre. Pour en savoir plus sur la résolution des problèmes de compilation dans Cloud Build, consultez la section Résoudre les erreurs de compilation.

Le quota quotidien n'est pas réinitialisé après la recréation

Après avoir supprimé une instance Secure Source Manager et l'avoir recréée avec le même ID d'instance le même jour, vous pouvez recevoir une erreur indiquant que le quota est épuisé ou que la limite est atteinte pour l'analyse des identifiants.

Ce problème se produit, car le quota d'analyse des identifiants est un quota de débit quotidien lié à l'ID d'instance. Si vous supprimez et recréez une instance avec le même ID le même jour, l'utilisation du quota n'est pas réinitialisée.

Pour résoudre ce problème, vous pouvez effectuer l'une des opérations suivantes :

  • Attendez le lendemain pour que l'utilisation du quota quotidien soit automatiquement réinitialisée à 0.
  • Recréez l'instance à l'aide d'un ID d'instance différent et unique.
  • Ignorez temporairement l'analyse des identifiants ou demandez une augmentation de quota. Pour en savoir plus, consultez la section Augmenter le quota disponible.