Análise de engenharia para GitLab autogerenciado por trás de uma VPN
Um padrão seguro para analisar dados de entrega privados do GitLab quando um aplicativo hospedado não consegue alcançar a rede do cliente.
Entenda a restrição da rede
Um back-end SaaS hospedado geralmente não pode chamar uma instância do GitLab que está disponível apenas em uma VPN corporativa ou rede privada. Adicionar todas as origens do cliente à configuração de implantação não é escalonável e pedir ao cliente para expor publicamente o GitLab enfraquece o limite de segurança. O navegador do usuário, entretanto, pode já ter acesso autorizado à rede enquanto estiver conectado à VPN. Isso cria um caminho prático para uma sincronização manual direta do navegador, desde que o produto trate o navegador como um limite não confiável e minimize o que sai dele.
Deixe o navegador chamar o GitLab diretamente
No modo direto do navegador, o usuário insere a origem do GitLab, o escopo do grupo e um token somente leitura na página. O JavaScript em execução no navegador chama a API GitLab por meio da conexão VPN existente. Ele normaliza apenas os metadados de entrega exigidos pelo produto e envia essa carga normalizada para o aplicativo hospedado. O token nunca deve ser incluído nessa carga útil, logs de aplicativos, monitoramento de erros ou análises. O armazenamento de conveniência opcional deve ser um armazenamento de sessão com escopo de guia, não um armazenamento local persistente, e fechar a guia deve remover a credencial.
Use as permissões práticas mais restritas
Crie um token destinado ao acesso à API somente leitura e escopo da sincronização para os grupos ou projetos que o workspace está autorizado a analisar. Valide a origem do GitLab como HTTPS, rejeite credenciais incorporadas em URLs e evite chamadas para hosts internos arbitrários sempre que possível. A rota de ingestão hospedada deve verificar de forma independente o gestor do espaço de trabalho inscrito, o tipo de fornecedor aceite, o esquema de carga útil, o tamanho máximo, o âmbito do repositório e o limite de taxa. Um token mantido pelo navegador reduz a exposição secreta do lado do servidor, mas não elimina a necessidade de validar tudo o que o navegador envia.
Otimize a sincronização em torno de páginas limitadas
Busque projetos e solicitações de mesclagem recentes com o maior tamanho de página compatível, respeite os cabeçalhos de paginação do GitLab e vincule o histórico a uma janela de tempo clara ou limite de registro. Evite uma solicitação por solicitação de mesclagem, a menos que uma métrica realmente precise de eventos detalhados. Carregue dados caros de revisão, participante ou iteração simultaneamente com um limite conservador e mostre o progresso por trabalho concluído, não por um botão giratório arbitrário. Resultados normalizados em cache no aplicativo para que os relatórios não repitam a busca da VPN. O modo direto do navegador manual não pode fornecer sincronização em segundo plano confiável ou webhooks após o fechamento da guia, portanto, rotule a atualização com honestidade.
Verifique a promessa de segurança
Durante um piloto, inspecione o painel de rede do navegador e confirme se o token foi enviado apenas para a origem GitLab do cliente. Verifique se as solicitações do aplicativo contêm metadados normalizados em vez de segredos brutos ou código-fonte. Feche a guia e verifique se o token desapareceu. Teste uma origem inválida, um token expirado, um usuário sem permissões de espaço de trabalho, uma resposta superdimensionada e uma sincronização parcial. Por fim, compare uma amostra de projetos, solicitações de mesclagem, revisores, rótulos, marcos e iterações com o próprio GitLab. Uma arquitetura segura é útil somente quando os usuários também podem confiar nas evidências resultantes.
Veja seu sistema de entrega com clareza.
Explore um espaço de trabalho Troodo semelhante ao de produção e veja como as evidências de entrega se tornam um resumo de gerenciamento focado.
Explore a demonstração ao vivo