Armazenamento e transmissão de credenciais de proxy em CI/CD sem vazamentos: guia passo a passo

As credenciais de proxy vazam nos logs públicos de build com mais frequência do que parece. Um simples curl -v desatento, uma variável exposta, uma senha dentro da URL — e seu login e senha já estão no histórico do pipeline, visíveis para toda a equipe. Neste guia, vamos mostrar como evitar isso.

Introdução: como as credenciais de proxy vazam em logs e histórico

Imagine uma situação típica. Você configura um build que acessa recursos externos via proxy Proxeon. Para testar a conexão rapidamente, você escreve um comando com a senha diretamente na URL: http://user:pass@host:port. O build passa, você comemora. Uma semana depois, descobre que a senha estava visível no log de cada execução, no histórico do shell no runner e até na saída de depuração do cliente.

Isso não é raro, é uma tendência. As credenciais de proxy têm uma propriedade desagradável: são necessárias em quase todas as chamadas de rede, então vazam facilmente para dezenas de lugares ao mesmo tempo.

O que você vai conseguir com este guia

Ao final do guia, você será capaz de configurar seu CI/CD para que as credenciais de proxy não apareçam em nenhum log, nem no histórico de comandos, nem no repositório. Você aprenderá a usar os segredos dos sistemas populares, desativar modos de depuração perigosos, trocar a senha com segurança sem parar os builds e verificar tudo com um script pronto.

Para quem é este guia

O material é voltado para engenheiros de nível intermediário: DevOps, desenvolvedores backend, QA-automatizadores. Se você já sabe executar um pipeline e sabe o que é uma variável de ambiente, vai se sentir confortável. Leitores avançados encontrarão seções sobre rotação e auditoria.

O que você precisa saber de antemão

A configuração básica das variáveis http_proxy e no_proxy não será abordada aqui — isso é tema de outro material. Presumimos que a conexão com o proxy já está funcionando e a tarefa agora é tornar o armazenamento das credenciais seguro.

Quanto tempo vai levar

Para ler e entender, cerca de 40 minutos. Para implementar em um pipeline, de 30 minutos a uma hora e meia, dependendo do sistema de CI. A rotação e a verificação de vazamentos podem ser adicionadas depois — cada uma leva de 15 a 20 minutos.

Preparação inicial: o que você vai precisar

Antes de começar, reúna tudo o que for necessário. Isso economiza tempo e evita interrupções no meio do trabalho.

Ferramentas e acessos

• Acesso ao seu projeto no CI/CD com permissão para editar configurações e segredos.
• Assinatura de proxy Proxeon ativa com login, senha, host e porta.
• Máquina local com curl, git, e interpretadores Python 3 e Node.js instalados, se você planeja usar os exemplos.
• Editor de texto para editar os arquivos de configuração do pipeline.

Requisitos de sistema

Não há requisitos especiais. Tudo funciona em Linux, macOS e Windows. Os runners de CI geralmente são baseados em Linux, então a maioria dos exemplos usa sintaxe bash. Para runners Windows, mencionaremos as diferenças separadamente.

O que preparar com antecedência

Anote as credenciais atuais do proxy em um gerenciador de senhas confiável. Elas serão úteis ao configurar os segredos. Não as armazene em um arquivo de texto comum na sua área de trabalho.

Dica: Crie uma conta de proxy separada para CI, se o seu plano Proxeon permitir. Assim, a comprometimento das credenciais do build não afetará suas credenciais pessoais e vice-versa.

Backup da configuração

Antes de alterar o pipeline, faça uma cópia do arquivo de configuração atual. Basta copiar o .gitlab-ci.yml, o arquivo de workflow ou o Jenkinsfile para uma pasta separada fora do repositório.

⚠️ Atenção: Nunca faça backup commitando no mesmo repositório com a senha dentro. Mesmo em um branch temporário, as credenciais entrarão para o histórico do git para sempre.

Conceitos básicos: termos em linguagem simples

Vamos entender as palavras-chave para não nos confundirmos.

Credenciais de proxy

São o login e a senha que seu cliente usa para confirmar o direito de usar o proxy Proxeon. Às vezes, em vez de login e senha, usa-se vinculação por IP, mas aqui estamos falando especificamente do par login-senha.

Segredo no CI

Segredo é um armazenamento especial dentro do sistema de CI onde você coloca um valor sensível. O sistema o criptografa e o injeta no build como uma variável de ambiente, ocultando-o automaticamente nos logs.

Mascaramento

Mascaramento é quando o CI substitui o valor do segredo na saída por asteriscos. Se a senha for impressa acidentalmente, você verá algo como [MASKED]. Isso nem sempre funciona perfeitamente, por isso vamos combinar várias proteções.

Cabeçalho Proxy-Authorization

Quando o cliente autentica no proxy, ele envia o cabeçalho HTTP Proxy-Authorization com as credenciais codificadas. Em modo de depuração detalhado, muitos clientes imprimem esse cabeçalho por completo. Descodificá-lo é trivial, portanto, essa saída é considerada um vazamento.

Escopo

Escopo determina quais builds têm acesso ao segredo. Um segredo bem limitado é visível apenas para branches protegidos e não chega a forks ou pull requests externos.

Dica: Lembre-se do princípio principal: o segredo deve existir na memória do processo apenas pelo tempo necessário e não deve deixar rastros no disco ou na saída.

Passo 1: Entenda a principal armadilha — senha na URL

Objetivo desta etapa: aprender a reconhecer a fonte mais comum de vazamento e abandoná-la para sempre.

O erro mais comum é colocar as credenciais diretamente na URL do proxy: http://user:pass@host:port. É conveniente, então quase todos os iniciantes fazem isso. O problema é que essa URL aparece em lugares inesperados.

Onde exatamente a senha da URL aparece

1. Lista de processos. O comando ps no runner mostrará a linha completa de execução, incluindo a senha. Qualquer processo na mesma máquina pode lê-la.
2. Logs do próprio proxy. Alguns logs de servidor registram a string de conexão. Se a URL contém a senha, ela vai para o log.
3. Histórico de comandos do shell. O arquivo .bash_history guarda tudo o que você digitou, incluindo a senha na URL.
4. Saída de depuração do cliente. Ao executar com o modo detalhado, o cliente imprime o endereço de destino junto com as credenciais.
5. Logs de CI. Se a variável com a URL não estiver marcada como segredo, ela é impressa em texto aberto na etapa echo ou em caso de erro.

Verifique agora mesmo. Execute um comando inofensivo em qualquer máquina e veja a lista de processos.

curl -x http://myuser:mypass@proxy.proxeon.net:8080 https://example.com & ps aux | grep curl

Você verá sua senha em texto aberto na saída do ps. Essa é exatamente a falha que estamos corrigindo.

⚠️ Atenção: Mesmo que o build seja privado, a lista de processos do runner pode ser acessada por outro processo, outro job em um runner compartilhado ou uma ferramenta de monitoramento. Considere a senha na URL como pública.

Resultado esperado: você entende os cinco pontos de vazamento e nunca mais escreverá a senha dentro do endereço do proxy.

✅ Verificação: execute o comando de teste acima e confirme que você vê a senha na saída do ps. Se vir, você reproduziu o problema corretamente e está pronto para resolvê-lo.

Passo 2: A maneira correta — variáveis de ambiente e arquivos de credenciais

Objetivo desta etapa: mover as credenciais da URL para armazenamentos seguros — variáveis de ambiente e arquivos especiais.

A ideia é simples. O login e a senha são armazenados separadamente do endereço. O cliente os lê do ambiente ou de um arquivo com permissões restritas, e não da linha de comando. Assim, eles não aparecem na lista de processos nem no histórico.

Opção A: variáveis de ambiente

Muitos clientes sabem ler credenciais de proxy do ambiente. Vamos aos exemplos.

curl via variável de ambiente

Defina o endereço do proxy sem credenciais e passe login e senha com uma flag separada, cujo valor vem de uma variável.

1. Exporte uma variável com as credenciais no ambiente (no CI, isso será feito pelo segredo; localmente, por uma fonte segura).
2. Passe o valor via flag -U, não na URL.

export PROXY_CREDS="$PROXEON_USER:$PROXEON_PASS"; curl -x http://proxy.proxeon.net:8080 -U "$PROXY_CREDS" https://example.com

Mesmo a flag -U com uma variável é melhor do que a senha na URL, mas ainda é visível no ps. Por isso, o arquivo de credenciais, descrito abaixo, é preferível.

Python requests

Em Python, leia as credenciais do ambiente com os.environ e monte o dicionário de proxies em memória. Não imprima nada.

import os, requests; user=os.environ['PROXEON_USER']; pwd=os.environ['PROXEON_PASS']; proxy=f'http://{user}:{pwd}@proxy.proxeon.net:8080'; r=requests.get('https://example.com', proxies={'http':proxy,'https':proxy}); print(r.status_code)

Aqui a senha permanece em uma variável dentro do processo Python e não entra na linha de comando. O importante é não registrar a variável proxy por completo.

Node.js

Em Node, também pegue as credenciais de process.env e crie o agente de proxy no código.

const user=process.env.PROXEON_USER; const pass=process.env.PROXEON_PASS; const proxyUrl=`http://${user}:${pass}@proxy.proxeon.net:8080`; const {HttpsProxyAgent}=require('https-proxy-agent'); const agent=new HttpsProxyAgent(proxyUrl); fetch('https://example.com',{agent}).then(r=>console.log(r.status));

Dica: Em qualquer linguagem, registre no log apenas o status da resposta e, se necessário, o host de destino. Nunca imprima o objeto de configuração do proxy por completo — ele contém a senha.

Opção B: arquivo .netrc

O arquivo .netrc é a forma clássica de armazenar credenciais separadamente dos comandos. O curl sabe lê-lo automaticamente.

1. Crie o arquivo .netrc no diretório home do runner em tempo real, a partir do segredo do CI.
2. Adicione uma linha com a máquina, o login e a senha.
3. Defina as permissões para 600, para que apenas o proprietário possa ler.
4. Execute o curl com a flag para usar o netrc.

printf 'machine proxy.proxeon.net login %s password %s' "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc; chmod 600 ~/.netrc; curl --netrc -x http://proxy.proxeon.net:8080 https://example.com

Agora a senha não aparece na linha de comando nem na lista de processos. Ela está em um arquivo com permissões 600, que você removerá ao final do build.

⚠️ Atenção: As permissões 600 são obrigatórias. Sem elas, o curl pode se recusar a ler o arquivo, e o próprio arquivo fica acessível a outros usuários na máquina.

Opção C: arquivo de configuração do curl

O curl pode ler flags de um arquivo de configuração. Coloque o proxy e as credenciais nele e defina as permissões 600.

printf 'proxy = http://proxy.proxeon.net:8080\nproxy-user = "%s:%s"\n' "$PROXEON_USER" "$PROXEON_PASS" > ~/.curlrc; chmod 600 ~/.curlrc; curl https://example.com

Com o .curlrc com permissões 600, as credenciais não são visíveis no processo nem no histórico.

Opção D: arquivo de configuração do aplicativo

Se você tem seu próprio aplicativo que lê configuração, armazene as credenciais de proxy em um arquivo fora do repositório. No repositório, mantenha apenas um modelo com placeholders, e os valores reais são inseridos no runner a partir dos segredos.

Resultado esperado: em nenhum exemplo a senha aparece na linha de comando ou na lista de processos. Ela vive em uma variável dentro do processo ou em um arquivo com permissões 600.

✅ Verificação: execute qualquer exemplo e, paralelamente, rode ps aux | grep curl. A senha não deve aparecer. Se estiver usando netrc, verifique as permissões com ls -l ~/.netrc — deve ser -rw-------.

Passo 3: Segredos em CIs populares — GitHub Actions, GitLab CI, Jenkins

Objetivo desta etapa: colocar as credenciais de proxy no armazenamento protegido do seu sistema de CI e usá-las sem vazamentos.

GitHub Actions

No GitHub, os segredos são armazenados no nível do repositório ou da organização.

1. Abra o repositório e vá para as configurações Settings.
2. No menu esquerdo, encontre Secrets and variables, depois Actions.
3. Clique em New repository secret.
4. Digite o nome, por exemplo PROXEON_USER, e o valor — seu login. Salve.
5. Repita para PROXEON_PASS com a senha.

No workflow, acesse os segredos pelo contexto secrets e passe-os para a etapa como variáveis de ambiente.

steps: - name: request env: PROXEON_USER: ${{ secrets.PROXEON_USER }} PROXEON_PASS: ${{ secrets.PROXEON_PASS }} run: printf 'machine proxy.proxeon.net login %s password %s' "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc; chmod 600 ~/.netrc; curl --netrc -x http://proxy.proxeon.net:8080 https://example.com

O GitHub mascara automaticamente os valores dos segredos nos logs. Se a senha for impressa acidentalmente, você verá três asteriscos.

⚠️ Atenção: Por padrão, os segredos não estão disponíveis em workflows executados a partir de forks via pull_request. Não altere esse comportamento para pull_request_target sem necessidade extrema — isso permitiria que um colaborador externo obtivesse suas credenciais.

GitLab CI

No GitLab, os segredos são chamados de variáveis de CI/CD e são configurados no projeto.

1. Abra o projeto, vá em Settings, depois CI/CD.
2. Expanda a seção Variables e clique em Add variable.
3. Digite a chave PROXEON_USER e o valor.
4. Marque a caixa Masked para ocultar o valor nos logs.
5. Marque a caixa Protected para que a variável seja acessível apenas em branches e tags protegidos.
6. Repita para PROXEON_PASS.

No .gitlab-ci.yml, as variáveis estão disponíveis automaticamente como ambiente.

request: script: - printf 'machine proxy.proxeon.net login %s password %s' "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc - chmod 600 ~/.netrc - curl --netrc -x http://proxy.proxeon.net:8080 https://example.com

Dica: A flag Masked no GitLab funciona apenas para valores que atendem às regras: comprimento mínimo, sem quebras de linha, conjunto de caracteres base64. Se a senha não for mascarada, o GitLab mostrará um aviso ao salvar. Nesse caso, troque a senha por uma que atenda aos requisitos.

Jenkins

No Jenkins, as credenciais são armazenadas na seção Credentials e são injetadas pelo plugin Credentials Binding.

1. Abra Manage Jenkins, depois Credentials.
2. Escolha o escopo, por exemplo System e Global credentials.
3. Clique em Add Credentials.
4. Escolha o tipo Username with password.
5. Digite o login e a senha do proxy, defina um ID claro, por exemplo proxeon-creds.

No Jenkinsfile, envolva o uso em um bloco withCredentials. O Jenkins mascara os valores no console.

withCredentials([usernamePassword(credentialsId: 'proxeon-creds', usernameVariable: 'PROXEON_USER', passwordVariable: 'PROXEON_PASS')]) { sh 'printf "machine proxy.proxeon.net login %s password %s" "$PROXEON_USER" "$PROXEON_PASS" > ~/.netrc; chmod 600 ~/.netrc; curl --netrc -x http://proxy.proxeon.net:8080 https://example.com' }

⚠️ Atenção: O Jenkins mascara apenas os valores definidos via Credentials Binding. Se você montar a senha como uma string em Groovy e imprimi-la, o mascaramento não funcionará. Trabalhe com as credenciais apenas dentro do bloco withCredentials e somente nas etapas sh.

Resultado esperado: as credenciais estão no armazenamento protegido do seu sistema de CI, são injetadas no build como ambiente e mascaradas nos logs.

✅ Verificação: execute um build e abra o log. Confirme que, em vez da senha, você vê asteriscos ou um marcador de mascaramento. Tente imprimir a variável deliberadamente com echo — o sistema deve ocultá-la.

Passo 4: Logs — desative os modos que imprimem Proxy-Authorization

Objetivo desta etapa: remover a saída detalhada onde ela revela o cabeçalho de autorização e manter um nível de log seguro.

O mascaramento do CI não é uma bala de prata. Se o cliente imprime o cabeçalho Proxy-Authorization em base64 e o sistema não conhece a senha original literalmente, o mascaramento pode falhar. Portanto, desative os modos perigosos na origem.

curl

A flag -v e, especialmente, --trace imprimem cabeçalhos, incluindo a autorização do proxy. No CI, use o modo silencioso.

1. Remova -v, --verbose, --trace e --trace-ascii dos comandos do build.
2. Para controle de erros, use -sS: silencioso, mas mostra erros.
3. Se precisar depurar, use --trace apenas localmente, nunca no CI.

curl -sS --netrc -x http://proxy.proxeon.net:8080 https://example.com -o /dev/null -w '%{http_code}'

Assim, você obtém apenas o código de resposta, sem nenhum cabeçalho na saída.

Python requests

A biblioteca requests não imprime credenciais por padrão, mas o logging do urllib3 no nível DEBUG exibe os cabeçalhos das requisições. Mantenha o nível de log em WARNING ou INFO.

import logging; logging.getLogger('urllib3').setLevel(logging.WARNING)

Dica: Se, para diagnóstico, você ainda precisar do DEBUG, adicione um filtro de log que remova o cabeçalho Proxy-Authorization das mensagens. Mas é mais fácil diagnosticar localmente e manter WARNING no CI.

Node.js

No Node, evite definir a variável NODE_DEBUG=http no CI — ela exibe os cabeçalhos. Também não imprima o objeto do agente nem o objeto da requisição por completo.

1. Remova NODE_DEBUG do ambiente do runner.
2. Nos handlers de erro, imprima apenas error.message, não o objeto inteiro.
3. Não use bibliotecas de log de requisições HTTP em builds de produção.

⚠️ Atenção: O stack trace de uma exceção não tratada também pode conter a URL do proxy com credenciais, se você montou a URL com a senha. Essa é mais uma razão para não colocar a senha na URL e usar netrc ou campos separados.

Resultado esperado: nenhuma ferramenta no CI imprime o cabeçalho de autorização ou a URL completa do proxy.

✅ Verificação: execute um build e pesquise no log as strings Proxy-Authorization, Basic e o nome do seu usuário. Não deve haver nenhuma correspondência.

Passo 5: Rotação da senha do proxy sem interromper os builds

Objetivo desta etapa: aprender a trocar a senha de modo que os builds não falhem e a senha antiga deixe de funcionar.

A senha do proxy precisa ser trocada periodicamente e, obrigatoriamente, após qualquer suspeita de vazamento. A tarefa é fazer isso sem janela de indisponibilidade.

Estratégia de sobreposição

A situação ideal é quando, por algum tempo, tanto a senha antiga quanto a nova funcionam. Se o seu plano Proxeon permitir criar uma segunda conta ou um conjunto adicional de credenciais, use isso.

1. Crie novas credenciais de proxy no painel do Proxeon, sem excluir as antigas.
2. Adicione os novos valores nos segredos do CI com nomes temporários, por exemplo PROXEON_USER_NEW.
3. Mude o pipeline para os novos nomes em um branch separado e execute um build.
4. Confirme que o build passa com as novas credenciais.
5. Substitua os valores dos segredos principais PROXEON_USER e PROXEON_PASS pelos novos.
6. Remova os segredos temporários.
7. Revogue as credenciais antigas no painel do Proxeon.

Assim, em todos os momentos há um conjunto de credenciais funcionando e os builds não falham.

Se a sobreposição não estiver disponível

Quando houver apenas um par de credenciais, atue em uma janela tranquila.

1. Escolha um horário com baixa atividade de builds.
2. Pause a execução de novos pipelines por alguns minutos.
3. Troque a senha no painel do Proxeon.
4. Atualize imediatamente o valor do segredo no CI.
5. Execute um build de verificação.
6. Retome a operação normal.

Dica: Crie um procedimento simples de rotação e mantenha-o junto à descrição do pipeline. Em uma situação de estresse após um vazamento, uma lista de passos pronta economiza tempo e nervos.

⚠️ Atenção: Após a troca da senha, remova o arquivo netrc ou curlrc antigo do runner, se ele estiver em cache entre builds. Caso contrário, o cliente continuará usando as credenciais antigas.

Resultado esperado: a senha foi trocada, os novos builds usam as novas credenciais e a senha antiga não funciona mais.

✅ Verificação: tente executar uma requisição com a senha antiga — deve retornar um erro de autorização do proxy. O novo build, no entanto, passa com sucesso.

Passo 6: Verificação de vazamento — script de auditoria pronto

Objetivo desta etapa: garantir que as credenciais não estejam em artefatos, logs e repositório, e automatizar essa verificação.

Onde procurar

• Artefatos do build: arquivos gerados, relatórios, dumps.
• Logs do pipeline, incluindo execuções antigas.
• Histórico do repositório git.
• Caches e arquivos temporários do runner.

Busca em artefatos e logs

Baixe os artefatos e logs para uma pasta local e pesquise por marcadores característicos: nome de usuário, parte da senha, a palavra Basic e o cabeçalho de autorização.

grep -RniE 'proxy-authorization|Basic [A-Za-z0-9+/=]{8,}|proxeon.*login|:[^@/]+@proxy' ./artifacts ./logs

O script procura o cabeçalho de autorização, strings base64 após a palavra Basic, o padrão de login no netrc e o sinal de senha na URL antes do @. Qualquer correspondência é motivo de investigação.

Busca no histórico do git

A senha pode ter entrado em um commit antigo. Verifique todo o histórico.

git log -p -S 'proxy.proxeon.net' --all | grep -nE ':[^@/]+@proxy|password [^ ]+'

⚠️ Atenção: Se a senha for encontrada no histórico do git, simplesmente excluir o arquivo não basta — ela permanecerá nos commits antigos. É necessário reescrever o histórico com ferramentas especiais e, o mais importante, trocar a senha imediatamente. Considere essa senha como comprometida.

Automação no pipeline

Adicione um job separado que escaneie os artefatos gerados antes da publicação e falhe se encontrar algo. Esse salvaguarda detecta vazamentos antes que eles cheguem ao mundo externo.

leak_check: script: - if grep -RniE 'proxy-authorization|Basic [A-Za-z0-9+/=]{8,}' ./artifacts; then echo 'LEAK DETECTED'; exit 1; fi

Dica: Além disso, configure scanners de segredos prontos na etapa de pre-commit localmente. Eles detectam credenciais antes mesmo do commit, evitando que entrem no repositório.

Resultado esperado: a auditoria manual e o job automático confirmam que as credenciais não estão em lugar nenhum.

✅ Verificação: execute o script de auditoria — deve terminar sem correspondências. Em seguida, coloque deliberadamente uma string de teste com o marcador Basic em um artefato e confirme que o script a encontra e falha.

Passo 7: Checklist antes de colocar o pipeline em produção

Objetivo desta etapa: fazer a verificação final antes de ativar o pipeline.

Percorra a lista e marque cada item. Se ao menos um não estiver marcado, não coloque o pipeline em produção.

1. A senha do proxy não está escrita em nenhuma URL do tipo user:pass@host.
2. O login e a senha estão armazenados apenas nos segredos do CI, não em arquivos do repositório.
3. Os segredos estão marcados como mascaráveis e protegidos.
4. Os segredos não estão disponíveis para builds de forks ou pull requests externos.
5. As flags de modo detalhado e rastreamento foram removidas dos comandos.
6. O nível de log das bibliotecas HTTP não é DEBUG.
7. Variáveis de depuração como NODE_DEBUG estão ausentes no ambiente do runner.
8. Os arquivos netrc e curlrc são criados dinamicamente e têm permissões 600.
9. Os arquivos de credenciais são removidos no final do build ou estão em um runner efêmero.
10. O pipeline tem um job de verificação de vazamento.
11. O histórico do git foi verificado e não contém credenciais.
12. Existe um procedimento de rotação de senha.

Dica: Salve este checklist como modelo e anexe-o a cada novo pipeline que use proxy. A padronização reduz o número de erros.

✅ Verificação: todos os doze itens estão marcados. Somente agora o pipeline está pronto para produção.

Verificação do resultado: como garantir que tudo funciona

Vamos montar uma verificação final em um único cenário.

Checklist de operacionalidade

• O build acessa com sucesso o proxy Proxeon e obtém as respostas esperadas.
• No log do build, não há senha, login, strings base64 de autorização ou URL completa do proxy.
• Na lista de processos do runner durante a requisição, a senha está ausente.
• Os artefatos estão limpos; o script de auditoria não encontra correspondências.
• Os segredos são mascarados mesmo em um echo intencional.

Como testar

1. Execute o pipeline completo do início ao fim.
2. Abra o log e pesquise pelo nome de usuário — não deve haver correspondências.
3. Baixe os artefatos e execute o script de auditoria neles.
4. Verifique o job de verificação de vazamento — deve passar verde.

Indicadores de sucesso

O sucesso se parece assim: build verde, requisições através do proxy funcionam e a busca em todos os lugares possíveis não encontra nenhum fragmento das credenciais. Se for esse o caso, você atingiu o objetivo do guia.

Erros comuns e soluções

Vamos analisar problemas frequentes com o esquema problema, causa, solução.

Problema 1: a senha ainda aparece no log

Causa: a variável foi criada como comum, não como segredo, ou não está marcada como mascarável.

Solução: mova o valor para a seção de segredos, ative o mascaramento e verifique se o nome da variável corresponde ao do arquivo de configuração e do armazenamento.

Problema 2: o mascaramento não funciona no GitLab

Causa: a senha contém caracteres ou quebras de linha não permitidos para mascaramento.

Solução: troque a senha por uma string composta por letras, números e caracteres permitidos, com comprimento suficiente e que atenda aos requisitos de mascaramento.

Problema 3: curl não lê o netrc

Causa: o arquivo tem permissões incorretas ou não está no diretório home.

Solução: defina as permissões 600 com chmod e verifique se o caminho do arquivo corresponde ao esperado, ou especifique o caminho com a flag netrc-file.

Problema 4: senha no stack trace em caso de erro

Causa: a URL do proxy foi montada com as credenciais, e o cliente a imprime na exceção.

Solução: mude para netrc ou campos separados de login e senha, para que a URL não contenha credenciais, e imprima apenas a mensagem de erro.

Problema 5: a senha antiga continua sendo usada após a rotação

Causa: o arquivo netrc ou curlrc em cache permaneceu no runner.

Solução: remova os arquivos de credenciais no final de cada build e use runners efêmeros, onde o sistema de arquivos é limpo entre execuções.

Problema 6: o segredo vazou em um fork-pull-request

Causa: um modo que dá acesso a segredos para PRs externos está ativado.

Solução: desative esse modo, execute builds com segredos apenas para branches confiáveis e faça a verificação de PRs externos sem acesso ao proxy.

Problema 7: senha encontrada no histórico do git

Causa: em algum momento, as credenciais foram commitadas em um arquivo de configuração.

Solução: troque a senha imediatamente e, em seguida, reescreva o histórico do repositório, removendo os dados sensíveis de todos os commits.

Recursos adicionais: proteção avançada

Quando a proteção básica estiver configurada, você pode reforçá-la.

Gerenciador de segredos externo

Em vez de armazenar as credenciais no próprio sistema de CI, conecte um gerenciador de segredos externo. O pipeline recebe as credenciais via token de curta duração apenas durante o build. Assim, os segredos não ficam nas configurações do projeto permanentemente.

Tokens de curta duração em vez de senha

Se a infraestrutura do Proxeon e o seu esquema de acesso permitirem, prefira tokens temporários com prazo de validade limitado. Mesmo que vazem, esses tokens se tornam inúteis rapidamente.

Separação de credenciais por ambiente

Use credenciais diferentes para builds de teste e produção. A comprometimento das credenciais de teste não afetará os processos de produção.

Dica: Configure alertas de atividade anômala na conta de proxy. Um aumento súbito de requisições ou conexões de origens inesperadas é um sinal de possível vazamento e exige rotação imediata.

Rotação automática

Equipes avançadas automatizam a rotação em um cronograma: um script cria novas credenciais, atualiza o segredo e revoga as antigas sem intervenção humana. Comece com o procedimento manual e adicione a automação quando o processo estiver bem estabelecido.

FAQ: perguntas frequentes

Posso simplesmente confiar no mascaramento do CI e não me preocupar?

Não. O mascaramento detecta apenas correspondências exatas de um valor conhecido. O cabeçalho em base64 ou uma saída parcial pode passar despercebido. Combine o mascaramento com a não utilização da senha na URL e a desativação de logs detalhados.

O que é mais seguro: variável de ambiente ou arquivo netrc?

O arquivo netrc com permissões 600 é preferível para curl, porque o valor não chega nem à lista de processos. Para código em Python e Node, variáveis de ambiente lidas dentro do processo são mais convenientes. Ambas as opções são seguras com uso cuidadoso.

Preciso excluir o arquivo de credenciais após o build?

Sim, se o runner for reutilizado. Em runners efêmeros, onde a máquina é destruída após o build, isso é menos crítico, mas excluir no final é um bom hábito em qualquer caso.

E se a senha do proxy contiver caracteres especiais?

Em netrc e em campos separados, caracteres especiais geralmente não são um problema. O problema surge ao inserir na URL, onde caracteres como @ e : quebram o parsing. Essa é mais uma razão para não colocar a senha na URL.

O requests imprime credenciais por conta própria?

Por padrão, não. O vazamento ocorre com o logging DEBUG do urllib3 ativado ou ao imprimir o objeto de configuração do proxy. Mantenha o logging em WARNING e não imprima as configurações por completo.

A senha é visível na lista de processos ao usar a flag proxy-user?

Sim, a flag na linha de comando é visível no ps. Portanto, para curl, prefira netrc ou curlrc, onde o valor não é passado como argumento.

Com que frequência devo trocar a senha do proxy?

A rotação planejada é razoável em um intervalo regular, por exemplo, trimestralmente, e imediatamente após qualquer suspeita de vazamento. O procedimento de rotação do passo 5 ajudará a fazer isso rapidamente.

Posso armazenar as credenciais em um arquivo criptografado no repositório?

Tecnicamente, sim, mas isso complica o processo e cria risco de vazamento da chave de criptografia. Os segredos do CI e gerenciadores externos resolvem o problema de forma mais simples e segura. Não invente seu próprio armazenamento sem necessidade.

O que fazer se um vazamento já ocorreu?

Aja na ordem: troque a senha do proxy imediatamente, revogue as credenciais antigas, encontre todos os pontos de vazamento com o script de auditoria, se necessário reescreva o histórico do git e analise a causa para que não se repita.

Essas recomendações servem para runners Windows?

Sim, os princípios são os mesmos. A sintaxe difere: em vez de export, use a forma de definir variáveis da sua shell; em vez de chmod, ajuste as permissões pelas propriedades do arquivo. A lógica de armazenamento e desativação de logs é idêntica.

Conclusão

Você percorreu o caminho do hábito inseguro de colocar a senha na URL até a proteção completa das credenciais de proxy em CI/CD. Vamos lembrar o que foi feito.

Você aprendeu a reconhecer os cinco pontos de vazamento e abandonou a senha no endereço do proxy. Moveu as credenciais para variáveis de ambiente e arquivos netrc, curlrc e configurações de cliente com permissões 600. Configurou segredos no GitHub Actions, GitLab CI e Jenkins com mascaramento e escopo limitado. Desativou logs detalhados que imprimem o cabeçalho de autorização no curl, Python requests e Node. Dominou a rotação da senha sem interromper os builds e montou um script de auditoria de vazamentos pronto. Finalmente, passou pelo checklist final antes da produção.

O que fazer a seguir. Implemente o checklist como etapa obrigatória de revisão para todos os pipelines que usam o proxy Proxeon. Adicione o job de verificação de vazamento a todos os projetos. Gradualmente, evolua para um gerenciador de segredos externo e tokens de curta duração quando o processo básico se tornar natural.

Onde evoluir. Estude práticas de gestão de segredos em escala organizacional, rotação automática e monitoramento de anomalias na conta de proxy. A segurança das credenciais não é uma configuração pontual, mas uma disciplina de engenharia contínua. Mas agora você tem uma base sólida sobre a qual construir todo o resto. Boas e seguras builds.