Impor políticas para GitHub Actions em sua empresa

O que são políticas para GitHub Actions?

As políticas empresariais controlam as opções disponíveis para os membros da empresa quando eles usam GitHub Actions.

Se você não aplicar políticas empresariais, os proprietários da organização e os usuários com a permissão "Gerenciar políticas de ações da organização" terão controle total sobre as GitHub Actions para suas organizações.

Como impor políticas

1. Navegue até sua empresa. Por exemplo, na página Enterprises em GitHub.com.
2. Na parte superior da página, clique em Policies.
3. Em " Policies", clique em Actions.
4. Depois de configurar cada política, clique em Salvar.

Para obter mais informações sobre cada seção da página "Políticas", continue a leitura.

Políticas

Na seção "Políticas", você pode controlar quais organizações da sua empresa podem usar GitHub Actions, com as seguintes opções:

• Habilitar GitHub Actions para todas as organizações
• Habilitar GitHub Actions para organizações específicas
• Desabilitar GitHub Actions para todas as organizações

Controlando o acesso a ações públicas e fluxos de trabalho reutilizáveis

As empresas geralmente desejam limitar o acesso a apenas um grupo bem testado de ações públicas e fluxos de trabalho reutilizáveis como parte de sua governança da cadeia de suprimentos. As políticas disponíveis no GitHub permitem controlar o acesso sem bloquear os fluxos de trabalho dinâmicos usados por code scanning e GitHub Code Quality.

Você pode impor controles estritos sem definir exceções ou configuração adicional para code scanning e GitHub Code Quality, utilizando as seguintes opções:

•         **Permitir todas as ações e fluxos de trabalho reutilizáveis**: é possível usar qualquer ação ou fluxo de trabalho reutilizável, independentemente de quem criou ou do local de definição.
  

•         **Permitir ações empresariais e fluxos de trabalho reutilizáveis**: somente ações e fluxos de trabalho reutilizáveis definidos em um repositório dentro da empresa podem ser usados. Bloqueia todo o acesso a ações criadas pelo GitHub, como a ação [`actions/checkout`](https://github.com/actions/checkout).
  

• Permitir a empresa e fluxos de trabalho reutilizáveis e ações selecionados que não são empresa: qualquer ação ou fluxo de trabalho reutilizável definido em um repositório dentro da empresa pode ser usado, além de qualquer ação ou fluxo de trabalho reutilizável que corresponda aos critérios especificados.

•         **Exigir que as ações sejam fixadas em um SHA de commit de comprimento completo**: todas as ações devem ser fixadas em um SHA de commit de comprimento completo para serem usadas. Isso inclui ações de sua empresa e ações criadas pelo GitHub. Fluxos de trabalho reutilizáveis ainda podem ser referenciados por tag. Para obter mais informações, consulte [AUTOTITLE](/actions/reference/security/secure-use#using-third-party-actions).
  

Permitir a empresa e fluxos de trabalho reutilizáveis e ações selecionados que não são empresa

Se você escolher essa opção, ações e fluxos de trabalho reutilizáveis em sua empresa serão permitidas, e você terá as seguintes opções para permitir outras ações e fluxos de trabalho reutilizáveis:

•         **Permitir ações criadas pelo GitHub:** permite todas as ações criadas pelo GitHub localizadas nas organizações [`actions`](https://github.com/actions) e [`github`](https://github.com/github).
  

•         **Permitir ações do Marketplace por criadores verificados:** permite todas as ações do GitHub Marketplace criadas por criadores verificados, rotuladas com <svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-verified" aria-label="The verified badge" role="img"><path d="m9.585.52.929.68c.153.112.331.186.518.215l1.138.175a2.678 2.678 0 0 1 2.24 2.24l.174 1.139c.029.187.103.365.215.518l.68.928a2.677 2.677 0 0 1 0 3.17l-.68.928a1.174 1.174 0 0 0-.215.518l-.175 1.138a2.678 2.678 0 0 1-2.241 2.241l-1.138.175a1.17 1.17 0 0 0-.518.215l-.928.68a2.677 2.677 0 0 1-3.17 0l-.928-.68a1.174 1.174 0 0 0-.518-.215L3.83 14.41a2.678 2.678 0 0 1-2.24-2.24l-.175-1.138a1.17 1.17 0 0 0-.215-.518l-.68-.928a2.677 2.677 0 0 1 0-3.17l.68-.928c.112-.153.186-.331.215-.518l.175-1.14a2.678 2.678 0 0 1 2.24-2.24l1.139-.175c.187-.029.365-.103.518-.215l.928-.68a2.677 2.677 0 0 1 3.17 0ZM7.303 1.728l-.927.68a2.67 2.67 0 0 1-1.18.489l-1.137.174a1.179 1.179 0 0 0-.987.987l-.174 1.136a2.677 2.677 0 0 1-.489 1.18l-.68.928a1.18 1.18 0 0 0 0 1.394l.68.927c.256.348.424.753.489 1.18l.174 1.137c.078.509.478.909.987.987l1.136.174a2.67 2.67 0 0 1 1.18.489l.928.68c.414.305.979.305 1.394 0l.927-.68a2.67 2.67 0 0 1 1.18-.489l1.137-.174a1.18 1.18 0 0 0 .987-.987l.174-1.136a2.67 2.67 0 0 1 .489-1.18l.68-.928a1.176 1.176 0 0 0 0-1.394l-.68-.927a2.686 2.686 0 0 1-.489-1.18l-.174-1.137a1.179 1.179 0 0 0-.987-.987l-1.136-.174a2.677 2.677 0 0 1-1.18-.489l-.928-.68a1.176 1.176 0 0 0-1.394 0ZM11.28 6.78l-3.75 3.75a.75.75 0 0 1-1.06 0L4.72 8.78a.751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018L7 8.94l3.22-3.22a.751.751 0 0 1 1.042.018.751.751 0 0 1 .018 1.042Z"></path></svg>.
  

•         **Permitir ou bloquear ações especificadas e fluxos de trabalho reutilizáveis:** Permite ações e fluxos de trabalho reutilizáveis que você especificar. Você pode especificar ações individuais e fluxos de trabalho reutilizáveis ou organizações e repositórios inteiros.
  

Ao especificar ações e fluxos de trabalho reutilizáveis, use a seguinte sintaxe:

• Para restringir o acesso a tags ou SHAs de commit específicos de uma ação ou um fluxo de trabalho reutilizável, use a mesma sintaxe usada no fluxo de trabalho para selecionar a ação ou o fluxo de trabalho reutilizável.
  • Para uma ação, a sintaxe é OWNER/REPOSITORY@TAG-OR-SHA. Por exemplo, use actions/javascript-action@v1.0.1 para selecionar uma tag ou actions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f para selecionar um SHA.
  • Para um fluxo de trabalho reutilizável, a sintaxe é OWNER/REPOSITORY/PATH/FILENAME@TAG-OR-SHA. Por exemplo, octo-org/another-repo/.github/workflows/workflow.yml@v1.
• Para especificar um padrão, use o caractere curinga, *.
  • Para permitir todas as ações e fluxos de trabalho reutilizáveis em organizações que começam com space-org, use space-org*/*.
  • Para permitir todas as ações e fluxos de trabalho reutilizáveis em repositórios que começam com octocat, use */octocat**@*.
• Para especificar vários padrões, use , para separar padrões.
  • Para permitir todas as ações e fluxos de trabalho reutilizáveis das organizações octocat e octokit, use octocat/*, octokit/*.
• Para bloquear padrões específicos, use o prefixo !.
  • Para permitir todas as ações e fluxos de trabalho reutilizáveis da organização space-org, mas bloquear uma ação específica como space-org/action, use space-org/*, !space-org/action@*.
  • Por padrão, somente ações e fluxos de trabalho reutilizáveis especificados na lista serão permitidos. Para permitir todas as ações e fluxos de trabalho reutilizáveis enquanto também bloqueia ações específicas, use *, !space-org/action@*.

As políticas nunca restringem o acesso a ações locais no sistema de arquivos do executor (em que o caminho uses: começa com ./).

Executores

Por padrão, qualquer pessoa com acesso de administrador a um repositório pode adicionar um executor auto-hospedado para o repositório, mas os executores auto-hospedados possuem alguns riscos:

• Não há garantia de que executores auto-hospedados sejam hospedados em máquinas virtuais limpas e efêmeras. Como resultado, eles podem ficar comprometidos por código não confiável em um fluxo de trabalho.
• Qualquer pessoa capaz de criar uma bifurcação do repositório e abrir uma solicitação de pull pode comprometer o ambiente do executor auto-hospedado, com a possibilidade de obter acesso a segredos e ao GITHUB_TOKEN, que pode ter acesso de gravação ao repositório.

Na seção "Executores", você pode mediar esses riscos ao desabilitar o uso de executores auto-hospedados em nível do repositório.

•         **Desabilitar para todas as organizações**: impede a criação de executores no nível do repositório.
  

•         **Desabilitar em todos os repositórios Enterprise Managed User (EMU)**: impede a criação de executores para repositórios pertencentes a contas de usuário gerenciadas.
  

Imagens personalizadas

Na seção "Imagens personalizadas", você pode controlar quais organizações em sua empresa têm permissão para criar e gerenciar imagens personalizadas com a seguinte política de acesso:

•         **Habilitar para todas as organizações**: todas as organizações, incluindo qualquer criada no futuro, podem usar ou criar imagens personalizadas.
  

•         **Habilitar para organizações específicas**: somente as organizações selecionadas podem usar ou criar imagens personalizadas.
  

•         **Desabilitar para todas as organizações**: nenhuma organização pode usar ou criar imagens personalizadas.
  

Políticas de retenção de imagens personalizadas

Você pode definir por quanto tempo as versões de imagem personalizada são retidas e quando elas ficam inativas.

•         **Máximo de versões por imagem**: limita quantas versões de cada imagem são retidas. Quando esse limite é excedido, as versões de imagem não usada mais antigas são excluídas automaticamente.
  

  * Padrão: 20 versões * Intervalo configurável: 1 a 100 versões

•         **Retenção de versão não utilizada**: exclui versões de imagem que não foram usadas por um número especificado de dias. As versões de imagem atribuídas a um pool de executores, mas não usadas de forma ativa, também são consideradas não utilizadas.
  

  * Predefinição: 30 dias * Intervalo configurável: 1 a 90 dias

•         **Idade máxima da versão**: desabilita versões de imagem que foram criadas anteriormente ao número de dias especificado. As versões de imagem desativadas só poderão ser usadas por executores quando o limite de política for aumentado.
  

  * Padrão: 60 dias * Intervalo configurável: 7 a 90 dias

Retenção de artefato e log

Por padrão, os artefatos e arquivos de log gerados pelos fluxos de trabalho são mantidos por 90 dias antes de ser excluídos automaticamente. Você pode alterar o período de retenção.

• Para repositórios públicos, você pode configurar um período entre 1 e 90 dias.
• Para repositórios privados e internos, você pode configurar um período entre 1 e 400 dias.

As mudanças se aplicam apenas a novos artefatos e arquivos de log.

Configurações de cache

Você pode configurar os limites máximos de retenção e tamanho de cache que serão aplicados em toda a sua empresa. Se você aumentar o "limite de remoção do tamanho do cache" acima dos 10 GB incluídos em seu plano, será cobrado pelo armazenamento adicional de entradas armazenadas em cache.

Por padrão:

• Os caches são mantidos por 7 dias antes da exclusão automática.
• O limite total de armazenamento em cache é de 10 GB por repositório.

Você pode personalizar essas configurações para definir limites máximos para retenção de cache e tamanho de armazenamento em cache em sua empresa:

•         **Retenção de cache**: configure até 90 dias para repositórios públicos ou 365 dias para repositórios privados e internos.
  

•         **Limite de remoção do tamanho** do cache: configure até 10.000 GB por repositório.
  

As configurações que você configura no nível da empresa atuam como limites máximos. Os proprietários da organização podem optar por configurar limites para sua organização, mas não podem exceder os limites definidos no nível da empresa. Os administradores do repositório podem optar por configurar limites para seus repositórios, mas não podem exceder os limites definidos no nível da organização.

Para obter mais informações sobre a remoção de cache, consulte Referência do cache de dependência.

Bifurcar fluxos de trabalho de solicitações de pull de colaboradores externos

Qualquer pessoa pode fazer um fork de um repositório público e, em seguida, enviar um pull request para propor alterações no fluxo de trabalho do repositório. Para evitar abusos, os fluxos de trabalho não serão executados automaticamente em pull requests criadas por alguns colaboradores.

Você pode configurar quais pull requests exigem aprovação antes de serem executadas.

•         **Exigir aprovação para colaboradores iniciantes que sejam novos no GitHub**. Exige aprovação para usuários que nunca confirmaram no repositório e têm contas novas do GitHub.
  

•         **Exigir aprovação para colaboradores iniciantes**. Exige aprovação para usuários que nunca confirmaram no repositório.
  

•         **Exigir aprovação para todos os colaboradores externos**. Requer aprovação para todos os usuários que não são membros da organização.
  

Bifurcar fluxos de trabalho de solicitações de pull em repositórios privados

Você pode controlar como os usuários podem executar fluxos de trabalho em eventos pull_request em repositórios privados e internos.

•         **Executar fluxos de trabalho de solicitações de pull de bifurcações**. Os usuários podem executar fluxos de trabalho de solicitações de pull de bifurcações. Por padrão, os fluxos de trabalho usarão um `GITHUB_TOKEN` com permissão somente leitura, sem acesso a segredos.
  

•         **Enviar tokens de gravação para fluxos de trabalho de solicitações de pull**. Os fluxos de trabalho usarão um `GITHUB_TOKEN` com permissão de escrita.
  

•         **Enviar segredos para fluxos de trabalho a partir de solicitações de pull**. Todos os segredos estão disponíveis para o pull request.
  

•         **Exigir aprovação para fluxos de trabalho de solicitações de pull de bifurcações**. Para execução de fluxos de trabalho em solicitações de pull de colaboradores sem permissão de gravação, será necessária a aprovação de alguém com permissão de gravação.
  

Se uma política for habilitada para uma empresa, ela poderá ser desabilitada seletivamente em organizações individuais ou repositórios. Se uma política estiver desabilitada para uma empresa, as organizações individuais ou repositórios não poderão habilitá-la.

Permissões de fluxo de trabalho

Na seção "Permissões de fluxo de trabalho", você pode definir as permissões padrão concedidas ao GITHUB_TOKEN.

•         **Permissões de leitura e gravação:** as permissões padrão para o `GITHUB_TOKEN` dependem de quando a empresa ou organização foi criada:
  

  * Criação a partir de 2 de fevereiro de 2023 – Tem como padrão o acesso somente leitura para todos os escopos. * Criação antes de 2 de fevereiro de 2023 – Tem como padrão o acesso de leitura e gravação para todos os escopos.

•         **Permissões de leitura de conteúdo e pacotes do repositório**: por padrão, `GITHUB_TOKEN` tem apenas acesso de leitura para os escopos `contents` e `packages`. A configuração mais permissiva não pode ser escolhida como padrão para organizações ou repositórios individuais.
  

Qualquer pessoa com acesso de gravação a um repositório pode modificar as permissões concedidas ao GITHUB_TOKEN para um fluxo de trabalho específico editando a chave permissions no arquivo de fluxo de trabalho.

          **Permitir que o GitHub Actions crie e aprove pull requests** está desabilitada por padrão. Se você habilitar essa configuração, o `GITHUB_TOKEN` poderá criar e aprovar pull requests.