Skip to main content
Use Repositories > Manage para verificar qual acesso ao Git você tem. Mantenha seu login pessoal separado do acesso compartilhado de build e das credenciais de serviços externos.

​
Escolha o acesso Git correto

  • Personal account: o Agent usa sua conta autorizada para inspeção interativa de código, pushes de branches e pull requests ou merge requests.
  • Workspace connection(s): os builds de ambiente em segundo plano usam as concessões de repositório do workspace, sem depender da sua sessão pessoal de chat. Somente administradores do workspace podem configurá-las.
As concessões do GitHub usam uma instalação de GitHub App; as do GitLab usam grupos e projetos selecionados. Siga Instale o app do provedor Git para conectar ou alterar o acesso compartilhado. Se um build não conseguir buscar um repositório, verifique Workspace connection(s). Se o Agent não conseguir fazer push da sua branch, verifique Personal account e suas permissões de escrita no repositório. Desconectar um tipo de acesso não remove o outro.

​
Recursos externos precisam de uma identidade separada

O acesso ao Git, por si só, não concede acesso à AWS, a um gerenciador de segredos ou a pacotes privados. Para um ambiente que precisa repetidamente de um serviço externo, prefira a federação de identidade de carga de trabalho (workload identity federation) quando o provedor oferecer suporte: um administrador estabelece a confiança no provedor e, em seguida, o sandbox em execução apresenta um JWT de carga de trabalho do Replit de curta duração para a troca de credenciais. Limite o público (audience), as claims, os papéis e as permissões de recursos no lado do provedor. A confiança pode ser mais ampla que um único sandbox se a política do provedor usar uma claim válida para todo o workspace. Os passo a passo da AWS e do Infisical mostram padrões concretos de federação e seus limites de confiança. Para uma credencial pontual necessária apenas no seu chat privado, use segredos do chat. Você pode fazer commit de scripts auxiliares revisados e de configurações que não sejam segredos; valores de credenciais, JWTs emitidos e tokens trocados nunca devem ir para o Git nem para uma imagem pré-construída.
Esses fluxos em acesso antecipado e as receitas de provedores devem ser revisados com base nas configurações atuais da sua organização. Os exemplos da AWS e do Infisical são receitas de documentação, não uma afirmação de que sua conta de nuvem ou uma troca de federação em produção foi testada.