Voltar ao Blog
    DevOps & Linux
    Segurança

    GitHub Actions com OIDC: deploy sem credenciais de longa duração

    Configure a relação de confiança entre GitHub Actions e nuvem, restrinja claims e evite transformar OIDC em acesso amplo ao deploy.

    Publicado em ·5 min de leitura·por Bernardo Gomes

    Guardar uma chave de nuvem permanente no CI facilita o primeiro deploy, mas amplia o impacto de um vazamento. Com OpenID Connect (OIDC), um job do GitHub Actions solicita um token de identidade e o troca por credenciais temporárias no provedor de nuvem. O provedor precisa confiar explicitamente nesse emissor e nas condições do token.

    O fluxo de confiança

    O job autorizado solicita um JWT ao emissor OIDC do GitHub. O provedor verifica o token e sua política de confiança; se as condições forem atendidas, emite credenciais limitadas no tempo para uma função. Configure audience e subject conforme o provedor e restrinja repositório, referência ou ambiente protegido. O formato do subject depende do contexto do workflow: confira o token e a documentação antes de escrever a regra.

    yaml
    permissions:
      contents: read
      id-token: write
    
    jobs:
      deploy:
        runs-on: ubuntu-latest
        environment: production
        steps:
          - uses: actions/checkout@v7.0.1
          # Autentique com a action oficial do seu provedor e uma role restrita.
          # Execute o deploy somente após validar a política de confiança.

    O bloco acima mostra as permissões do GitHub, não é uma configuração completa de nuvem. id-token: write permite solicitar um token OIDC; por si só, não concede acesso aos recursos. A role e a política de confiança no provedor são indispensáveis. Em produção, fixe actions por SHA completo e auditado e use somente as permissões necessárias.

    Evite o falso senso de segurança

    • Restrinja quem pode atualizar o workflow e use proteção de branch e ambiente para produção.
    • Não execute código de pull requests não confiáveis em jobs com acesso a segredos ou à role de produção.
    • Limite a role ao serviço e aos recursos necessários; prazo curto não corrige permissão excessiva.
    • Registre eventos de emissão e uso no provedor, teste negações e tenha um procedimento para revogar a confiança.
    • Separe ambientes de teste e produção com identidades e políticas próprias.

    Migre um ambiente de teste primeiro. Confirme que uma branch não autorizada não consegue assumir a role, que a implantação legítima funciona e que os logs identificam a execução. Depois remova a credencial antiga e monitore. OIDC reduz o tempo de exposição de credenciais; não substitui revisão de código, isolamento ou menor privilégio.

    Fontes