Dépannage

Cette page 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 d'administrateur de dépôt sur votre projet ni des autorisations nécessaires pour créer des dépôts dans l'instance Secure Source Manager.

Pour remédier à ce problème :

  • Activez l'API Secure Source Manager dans votre projet.
  • Demandez à votre administrateur de vous accorder les rôles suivants :
    • Rôle Administrateur de dépôt (roles/securesourcemanager.repoAdmin) sur votre projet.
    • Accesseur d'instances (roles/securesourcemanager.instanceAccessor) sur l'instance Secure Source Manager.
    • Créateur de dépôts d'instances (roles/securesourcemanager.instanceRepositoryCreator) sur 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 remédier à ce problème :

  • Exécuter 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

La connexion SSH échoue avec l'erreur "no matching"

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

  • 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 n'est pas compatible avec les algorithmes de chiffrement requis par Secure Source Manager. Cela peut se produire si vous utilisez un ancien client SSH 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 compatible avec ces algorithmes.

Échec des requêtes HTTPS Git avec une erreur d'autorisation refusée ou non autorisée

Lorsque des commandes Git sont tentées via HTTPS, un message d'erreur d'autorisation refusée ou non autorisée s'affiche.

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

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

Pour remédier à 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-la, puis authentifiez-vous à nouveau à l'aide de gcloud auth login avant de réessayer d'exécuter la commande Git.

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

    Linux

    1. Pour ajouter l'assistant 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'assistant d'authentification est ajoutée à votre configuration Git globale en exécutant la commande suivante :

      git config --list | grep credential

      Le résultat 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 la version de gcloud CLI en suivant les instructions de la section Installer Git et la Google Cloud CLI.

    2. Pour ajouter l'assistant 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'assistant d'authentification est ajoutée à votre configuration Git globale en exécutant la commande suivante :

      git config --list | grep credential

      Le résultat 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 de type 'credential-gcloud.sh' is not a git command, cela signifie 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 à la place.

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

Un jeton OAuth valide est requis comme mot de passe pour les opérations Git HTTPS. Cette opération est normalement gérée par l'assistant d'identifiants Git, mais elle 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 généralement que les informations utilisateur n'ont pas pu être extraites du jeton entrant. Plusieurs causes peuvent expliquer cette erreur :

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

    Reconnectez-vous à l'aide de gcloud auth login.

  • Votre jeton n'a pas un niveau d'accès suffisant. Les jetons OAuth doivent disposer des 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'Workload Identity 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. Connectez-vous à l'aide des identifiants par défaut de l'application :

      gcloud auth application-default login

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

      gcloud config set auth/git_helper_use_adc true

Échec des requêtes HTTPS Git sur macOS avec une 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 auprès de Secure Source Manager, même après une nouvelle authentification à l'aide de gcloud auth login.

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

  1. Ouvrez l'application Trousseaux 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" correspondant à *.*.sourcemanager.dev ou à l'URL de votre instance Secure Source Manager en effectuant un clic 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 authentifier à nouveau 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 Workload Identity pour les parcs GKE

Lorsque vous utilisez l'Workload Identity de 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.

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

Lorsque vous utilisez le sélecteur de produits de l'interface Web de Secure Source Manager, votre projet ne s'affiche pas.

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

Pour remédier à ce problème :

  • Effacez vos cookies en ajoutant ce qui suit à l'URL de votre instance Secure Source Manager : /_oauth/consent

    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 rencontrez peut-être 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 qui indique 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 de 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 de compilation Cloud Build comporte des options ou un format non valides.
  • L'agent de service Secure Source Manager ne dispose pas du rôle Créateur de jetons du compte de service sur le compte de service géré par l'utilisateur du dépôt.
  • Le compte de service géré par l'utilisateur ne dispose pas du rôle Utilisateur du compte de service sur le compte de service Cloud Build.
  • Le compte de service géré par l'utilisateur ne dispose pas du rôle Éditeur Cloud Build sur le projet dans lequel les builds sont exécutés.
  • La règle d'administration iam.disableCrossProjectServiceAccountUsage bloque l'utilisation du compte de service géré par l'utilisateur (si le compte de service se trouve dans un autre projet).

Pour résoudre ce problème :

  • Assurez-vous de suivre le schéma de fichier de déclencheurs approprié.
  • Vérifiez que tous les rôles requis sont accordés. Consultez Rôles de compte de service requis.
  • Si vous utilisez un compte de service géré par l'utilisateur dans un autre projet, vérifiez que la règle d'administration iam.disableCrossProjectServiceAccountUsage est désactivée dans le projet hébergeant le compte de service.

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

Si une compilation est déclenchée avec succès, mais échoue pendant l'exécution, l'état du commit associé est "Échec".

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

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 Résoudre les erreurs de compilation.

Push Git refusé en raison de la détection de données sensibles

Lorsque vous effectuez un push de commits vers un dépôt où l'analyse des secrets est activée, le push échoue avec un message d'erreur semblable à celui-ci :

remote: Push rejected: Sensitive data detected.

Ce problème se produit lorsque l'analyse des secrets ou un modèle d'inspection personnalisé identifie des informations sensibles dans l'historique de vos commits.

Pour remédier à ce problème :

  • Annulez le commit problématique à l'aide de git reset --soft et supprimez les informations sensibles avant de procéder à un nouveau commit.

  • Si les informations détectées sont acceptables et que vous disposez des autorisations appropriées, ignorez la vérification à l'aide de l'option push -o dlpskip=true :

    git push -o dlpskip=true origin BRANCH_NAME

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

Si vous supprimez une instance Secure Source Manager et la recréez le même jour avec le même ID d'instance, vous risquez de recevoir une erreur de quota épuisé ou de limite atteinte pour l'analyse des secrets.

Ce problème se produit, car le quota d'analyse des secrets est un quota de taux quotidien associé à 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 deuxième jour pour que l'utilisation du quota quotidien soit automatiquement réinitialisée à 0.
  • Recréez l'instance en utilisant un ID d'instance unique différent.
  • Ignorez temporairement l'analyse des secrets ou demandez une augmentation de quota. Pour en savoir plus, consultez Augmenter le quota disponible.

Erreur lors de la configuration du compte de service du dépôt

L'erreur suivante s'affiche lorsque vous essayez de créer ou de mettre à jour un dépôt avec un compte de service géré par l'utilisateur :

Permission denied on resource ...

Ce problème se produit lorsque vous ne disposez pas du rôle Utilisateur du compte de service (roles/iam.serviceAccountUser) sur le compte de service que vous essayez d'associer au dépôt. Secure Source Manager vérifie que vous êtes autorisé à agir en tant que compte de service avant de vous autoriser à l'associer au dépôt.

Pour résoudre ce problème, demandez à votre administrateur de vous attribuer le rôle d'utilisateur du compte de service sur le compte de service.