Resolver problemas

Nesta página, mostramos como resolver problemas com o Secure Source Manager.

Mensagem de erro ao criar um repositório

O seguinte erro aparece quando você tenta criar um repositório:

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

Esse problema ocorre quando:

• A API Secure Source Manager não está ativada no seu projeto.
• Você não tem o papel de administrador do repositório no seu projeto ou permissões para criar repositórios na instância do Secure Source Manager.

Para resolver o problema:

• Ative a API Secure Source Manager no seu projeto.
• Peça ao administrador para conceder a você os seguintes papéis:
  • Papel de administrador do repositório (roles/securesourcemanager.repoAdmin) no seu projeto.
  • Acessador de instâncias (roles/securesourcemanager.instanceAccessor) na instância do Secure Source Manager.
  • Criador de repositórios de instâncias (roles/securesourcemanager.instanceRepositoryCreator) na instância do Secure Source Manager.

Veja mais detalhes em Controle de acesso com o IAM.

Mensagem de erro ao clonar um repositório em um Mac

O seguinte erro aparece quando você tenta clonar um repositório:

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

Esse problema ocorre quando:

• A CLI gcloud é instalada usando o Homebrew ou outra instalação não padrão.
• git-credential-gcloud.sh não é adicionado ao seu PATH.

Para resolver o problema:

• Execute source $HOMEBREW_PREFIX/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/path.zsh.inc

• Verifique se git-credential-gcloud.sh está no seu caminho executando o seguinte comando:

  which git-credential-gcloud.sh
  

A conexão SSH falha com o erro "no matching"

Ao tentar operações do Git por SSH, você pode receber uma das seguintes mensagens de erro:

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

Esse problema ocorre quando o cliente SSH não oferece suporte aos algoritmos criptográficos exigidos pelo Secure Source Manager. Isso pode acontecer se você estiver usando um cliente SSH mais antigo ou se o cliente não estiver configurado para usar algoritmos compatíveis.

O Secure Source Manager exige um dos seguintes algoritmos:

• Algoritmos de troca de chaves:curve25519-sha256, diffie-hellman-group14-sha256
• Cifras:[e-mail], aes128-ctr, aes192-ctr, aes256-ctr, [e-mail], [e-mail]
• MACs: [e-mail], hmac-sha2-256

Para resolver o problema, atualize o cliente SSH para uma versão recente que ofereça suporte a esses algoritmos.

As solicitações HTTPS do Git falham com erro de permissão negada ou não autorizado

Quando os comandos do Git são tentados por HTTPS, uma mensagem de erro de permissão negada ou não autorizado é exibida.

Esse problema ocorre quando uma das seguintes situações acontece:

• O arquivo de configuração global do Git não tem o auxiliar de autenticação do Secure Source Manager.
• O armazenamento de credenciais integrado do Git está sendo usado em vez de chamar o auxiliar de autenticação do Secure Source Manager para receber uma credencial atualizada.
• Um auxiliar de credenciais do sistema está sendo usado em vez de chamar o auxiliar de autenticação do Secure Source Manager para receber uma credencial atualizada.
• Uma versão mais antiga da Google Cloud CLI é usada ao interagir com repositórios do Secure Source Manager usando HTTPS. O Secure Source Manager exige a Google Cloud CLI versão 395.0.0 ou mais recente.

Para resolver o problema:

1. Execute o seguinte comando para determinar o conteúdo da configuração global do Git.

   git config --list | grep credential
   

2. Se você encontrar uma linha semelhante a *credential*.helper=store no macOS ou credential.helper = manager no sistema operacional Windows, remova essas linhas e autentique novamente usando gcloud auth login antes de tentar o comando do Git novamente.

3. Se a resposta não incluir credential.https://*.*.sourcemanager.dev.helper=gcloud.sh no macOS ou Linux, ou credential.https://*.*.sourcemanager.dev.helper=gcloud.cmd no Windows, adicione o auxiliar de autenticação do Secure Source Manager à configuração global do Git:

   Linux

   1. Para adicionar o auxiliar de autenticação do Secure Source Manager à configuração global do Git, execute o seguinte comando:

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

   2. Valide se a linha do auxiliar de autenticação foi adicionada à configuração global do Git executando o seguinte comando:

      git config --list | grep credential
      

      A saída precisa incluir credential.https://*.*.sourcemanager.dev.helper=gcloud.sh.

   3. Autentique executando gcloud auth login.

   4. Execute um comando do Git para testar a autenticação.

   Windows

   1. Verifique a versão da CLI gcloud seguindo as instruções de instalação do Git e da Google Cloud CLI.

   2. Para adicionar o auxiliar de autenticação do Secure Source Manager à configuração global do Git, execute o seguinte comando:

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

   3. Valide se a linha do auxiliar de autenticação foi adicionada à configuração global do Git executando o seguinte comando:

      git config --list | grep credential
      

      A saída precisa incluir credential.https://*.*.sourcemanager.dev.helper=gcloud.cmd.

   4. Autentique executando gcloud auth login.

   5. Execute um comando do Git para testar a autenticação.

4. Se você definiu anteriormente a credencial do host do Git como gcloud.sh, mas recebeu um erro como 'credential-gcloud.sh' is not a git command, isso indica que o Git não consegue encontrar o script git-credential-gcloud.sh no PATH da sua máquina. Atualize o PATH ou substitua o gcloud.sh no arquivo gitconfig pelo caminho absoluto.

As solicitações HTTPS do Git falham com token inválido

Um token OAuth válido é necessário como senha para operações HTTPS do Git. Isso normalmente é processado pelo auxiliar de credenciais do Git, mas também pode funcionar com tokens OAuth gerados usando outras abordagens (por exemplo, credenciais padrão do aplicativo).

Se uma solicitação do Git for rejeitada devido a um token inválido, isso normalmente significa que as informações do usuário não puderam ser extraídas do token recebido. Há várias causas possíveis para esse erro:

• O login da CLI gcloud pode ter expirado.

  Faça login novamente usando gcloud auth login.

• O token não tem escopo suficiente. Os tokens OAuth precisam ter os seguintes escopos:

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

  Você pode verificar o escopo do token chamando curl https://oauth2.googleapis.com/tokeninfo?access_token=${TOKEN}

• Você está usando um token gerado pela identidade da carga de trabalho da frota do GKE:

  • Tokens brutos gerados pela identidade da carga de trabalho da frota do GKE não são compatíveis. Para mais informações, consulte O SSM retorna um erro ao usar tokens KSA com a identidade da carga de trabalho da frota do GKE.

• Você tem políticas da organização que impedem o uso de tokens fora de determinados perímetros, por exemplo, o Acesso baseado no contexto.

  Para resolver esse problema, defina a propriedade de configuração da CLI gcloud git_helper_use_adc como true e atualize as credenciais padrão do aplicativo (ADC):

  1. Defina a propriedade git_helper_use_adc:

     gcloud config set auth/git_helper_use_adc true
     

  2. Atualize o ADC:

     gcloud auth login --update-adc
     

As solicitações HTTPS do Git falham no macOS com erro 403 devido a credenciais desatualizadas

Ao realizar operações do Git por HTTPS no macOS, você pode receber um erro 403.

Esse problema pode ocorrer no macOS se você usar o Acesso às Chaves do iCloud, que pode interferir nos tokens de autenticação da CLI gcloud armazenando e sincronizando tokens desatualizados. Esses tokens desatualizados podem fazer com que a autenticação falhe com o Secure Source Manager, mesmo depois de você autenticar novamente usando gcloud auth login.

Para resolver o problema, exclua manualmente as credenciais desatualizadas do Acesso às Chaves:

1. Abra o aplicativo Acesso às Chaves no Mac (localizado em /Applications/Utilities/).
2. Pesquise sourcemanager.dev.
3. Exclua todas as entradas do tipo "senha da Internet" que correspondam a *.*.sourcemanager.dev ou ao URL da instância do Secure Source Manager clicando com o botão direito do mouse na entrada e selecionando Excluir.
4. Depois de excluir as entradas, tente a operação do Git novamente. Talvez seja necessário autenticar novamente com a CLI gcloud. Se as operações do Git continuarem falhando, execute gcloud auth login antes de tentar novamente.

O SSM retorna um erro ao usar tokens da conta de serviço do Kubernetes (KSA) com a identidade da carga de trabalho da frota do GKE

Ao usar a identidade da carga de trabalho da frota do GKE, os tokens KSA brutos não são compatíveis com o Secure Source Manager. O uso desses tokens resulta em um erro.

Para resolver esse problema, é necessário representar uma conta de serviço e vincular a carga de trabalho a uma conta de serviço do Google. Também é necessário adicionar a seguinte anotação à configuração da KSA:

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

O projeto não aparece no seletor de produtos da interface da Web

Ao usar o seletor de produtos da interface da Web do Secure Source Manager, seu projeto não aparece.

Esse problema ocorre quando você tem várias credenciais de login para o Secure Source Manager.

Para resolver o problema:

• Limpe os cookies anexando o seguinte ao URL da instância do Secure Source Manager: /_oauth/consent

  Por exemplo, se o URL da instância for https://my-instance-098765432123.us-central1.sourcemanager.dev/, insira https://my-instance-098765432123.us-central1.sourcemanager.dev/_oauth/consent na barra de endereço do navegador e faça login com as credenciais corretas.

O arquivo de acionadores não aciona builds

Se os builds não forem acionados conforme o esperado após o envio do arquivo de acionadores, talvez você tenha um dos seguintes problemas:

• O arquivo de acionadores não está na ramificação padrão. Para resolver o problema, mova o arquivo de acionadores para a ramificação padrão.
• O arquivo de acionadores tem um formato inválido. Esse erro é indicado por um banner na página do repositório que diz Build triggers configuration error: .... Para corrigir o problema, leia o esquema do arquivo de acionadores. Quando a configuração do arquivo de acionadores estiver correta, o banner na página do repositório vai dizer Valid build triggers configuration.

Erro de configuração dos acionadores de build

Depois de enviar o arquivo triggers.yaml para o repositório do Secure Source Manager, você recebe o seguinte erro exibido em um banner:

Build cannot be created.

Esse problema ocorre pelos seguintes motivos:

• O arquivo de configuração do Cloud Build tem opções ou formato inválidos.
• O agente de serviço do Secure Source Manager não tem o papel de Criador do token da conta de serviço na conta de serviço gerenciado pelo usuário do repositório.
• A conta de serviço gerenciado pelo usuário não tem o papel de Usuário da conta de serviço na conta de serviço do Cloud Build.
• A conta de serviço gerenciado pelo usuário não tem o papel de Editor do Cloud Build no projeto em que os builds são executados.
• A política da organização iam.disableCrossProjectServiceAccountUsage está bloqueando o uso da conta de serviço gerenciado pelo usuário (se a conta de serviço estiver em um projeto diferente).

Para corrigir esse problema:

• Confira se você está seguindo o esquema correto do arquivo de acionadores .
• Verifique se todos os papéis necessários foram concedidos. Consulte Papéis necessários da conta de serviço.
• Se você estiver usando uma conta serviço gerenciado pelo usuário em um projeto diferente, verifique se a política da organização iam.disableCrossProjectServiceAccountUsage está desativada no projeto que hospeda a conta de serviço.

O build falha durante a execução

Se um build for acionado corretamente, mas falhar durante a execução, o commit associado terá um status de commit de falha.

Para resolver um build com falha, na página do repositório, ao lado do status de commit com falha, clique em Detalhes.

O registro de execução do Cloud Build é aberto. Para mais informações sobre como resolver problemas de builds no Cloud Build, consulte Como resolver erros de build.

O push do Git foi rejeitado devido a dados sensíveis detectados

Ao enviar commits para um repositório com a verificação de secrets ativada, o push falha com uma mensagem de erro semelhante a esta:

remote: Push rejected: Sensitive data detected.

Esse problema ocorre quando a verificação de secrets ou um modelo de inspeção personalizado identifica informações sensíveis no histórico de commits.

Para resolver o problema:

• Reverta o commit problemático usando git reset --soft e remova as informações sensíveis antes de fazer o commit novamente.

• Se as informações detectadas forem aceitáveis e você tiver as permissões adequadas, ignore a verificação usando a opção de push -o dlpskip=true:

  git push -o dlpskip=true origin BRANCH_NAME
  

A cota diária não é redefinida após a recriação

Depois de excluir uma instância do Secure Source Manager e recriá-la com o mesmo ID de instância no mesmo dia, você poderá receber um erro de cota esgotada ou limite atingido para a verificação de secrets.

Esse problema ocorre porque a cota de verificação de secrets é uma cota de taxa diária vinculada ao ID da instância. Se você excluir e recriar uma instância com o mesmo ID no mesmo dia, o uso da cota não será redefinido.

Para resolver esse problema, siga um destes procedimentos:

• Aguarde até o segundo dia para que o uso da cota diária seja redefinido automaticamente para 0.
• Recrie a instância usando um ID de instância diferente e exclusivo.
• Pule a verificação de secrets temporariamente ou solicite um aumento de cota. Para mais informações, consulte Aumentar a cota disponível.

Erro ao configurar a conta de serviço do repositório

O seguinte erro aparece quando você tenta criar ou atualizar um repositório com uma conta serviço gerenciado pelo usuário:

Permission denied on resource ...

Esse problema ocorre quando você não tem o papel de Usuário da conta de serviço (roles/iam.serviceAccountUser) na conta de serviço que está tentando associar ao repositório. O Secure Source Manager verifica se você tem permissão para agir como a conta de serviço antes de permitir que você a associe ao repositório.

Para resolver esse problema, peça ao administrador para conceder a você o papel de usuário da conta de serviço na conta de serviço.