GitHub Actions secrets: implantar sem publicar senhas nem chaves

Publicado em 2026-10-26 por frfrand

Configurar segredos CI e permissões mínimas no GitHub Actions

GitHub Actions secrets: implantar sem publicar senhas nem chaves

A automação de um deploy perde sentido se, para usá-la, você terminar colando a senha do servidor em um YAML público. O GitHub Actions permite gerenciar segredos e tokens, mas também é preciso limitar quais workflows podem usá-los.

A ideia é resolver um problema de dados ou implantação que aparece em aplicações reais. Vamos ver o conceito sem rodeios, um exemplo de implementação e o que verificar antes de levá-lo para produção.

O que fazem os segredos do GitHub Actions

Os segredos e variáveis do Actions são configurados por repositório, ambiente ou organização, de acordo com as permissões. Os segredos não devem ser impressos nem enviados a artefatos. Para serviços em nuvem, credenciais efêmeras baseadas em OIDC podem ser mais seguras do que chaves permanentes, quando o provedor as suporta.

Não basta repetir uma receita se você não entender quem lê os dados, de qual processo e com quais permissões. Em um aplicativo com reservas, faturas ou usuários, uma condição de corrida ou uma política de acesso mal feita pode ser mais grave do que uma API lenta.

Um exemplo concreto

# Extracto ilustrativo de workflow
name: test
on: [push]
jobs:
  checks:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v4
      - run: echo 'Ejecutar pruebas antes del deploy'
# Secrets: se referencian desde secrets.*, nunca se escriben en YAML

Os nomes, tabelas e chaves deste exemplo são ilustrativos. Teste primeiro em um banco ou ambiente de homologação e adapte permissões, índices e versões. Quando houver operações de gravação, não execute consultas de exemplo sobre dados de clientes sem revisar o que elas modificam.

Passo a passo

Separe testes de publicação: nem todo push deve chegar automaticamente à produção.
Conceda permissions mínimos ao token GITHUB_TOKEN do workflow.
Guarde credenciais em Secrets e use ambientes protegidos com aprovação quando for o caso.
Revise permissões de PRs externas, forks e dependências de terceiros.
Verifique logs e artefatos para garantir que não contenham valores sensíveis.

No final, não fique com «o SQL não deu erro». Comprove o efeito real pela API e com testes de concorrência ou permissões, conforme o caso. Em bancos de dados, há erros que só aparecem quando dois usuários fazem algo ao mesmo tempo.

Exemplo de projeto de trabalho

Uma agência tem dois repositórios de clientes e implanta uma API Django em cada VPS. Uma credencial de implantação por cliente evita que um workflow comprometido acesse todos os projetos.

Esse cenário ajuda a distinguir desempenho de consistência. Acelerar uma consulta não adianta se permitir criar duas reservas para uma única vaga, nem um banco enorme resolve o fato de o backend permitir consultar dados de outro cliente.

O erro típico

Embora o GitHub mascare certos padrões, imprimir segredos transformados ou passá-los a processos de terceiros pode vazá-los. Não use pull_request_target com código não confiável sem analisar os riscos.

Também vale a pena ter um plano de recuperação. Antes de alterar esquema, usuários ou políticas, faça uma cópia verificável ou migração reversível e verifique se o aplicativo pode continuar funcionando durante a mudança.

Como resolveria com ArduMaker?

Com o ArduMaker você pode conectar repositórios Git e organizar implantações por Empresa. Se mantiver CI no GitHub Actions, separe permissões de testes e as credenciais mínimas necessárias para publicar cada projeto.

O ArduMaker permite implantar serviços a partir do Git e trabalhar com bancos de dados e processos dentro do VPS. O painel não substitui a lógica do seu aplicativo: transações, permissões e validações devem estar corretamente projetadas no código e no banco de dados.

Três verificações antes de publicar

Integridade: se uma solicitação for repetida ou falhar no meio do caminho, os dados terminam em um estado válido?

Segurança: um usuário autenticado pode acessar apenas suas informações, e a API utiliza uma identidade de banco com permissões mínimas?

Recuperação: você sabe restaurar os dados e reverter a versão de código compatível se uma atualização der errado?

Se você puder responder a essas três perguntas com provas, seu backend está bastante mais preparado do que quando você apenas verificou se o endpoint retornava 200.

Recursos para aprofundar

Para encerrar: escolha a solução mais simples que permita manter dados corretos, seguros e recuperáveis. O desempenho vem depois de medir.