Desabilitar ou limitar o GitHub Actions para sua organização

About GitHub Actions permissions for your organization

By default, GitHub Actions is enabled on all repositories and organizations. You can choose to disable GitHub Actions or limit it to actions and reusable workflows in your enterprise. For more information about GitHub Actions, see Writing workflows.

You can enable GitHub Actions for all repositories in your organization. When you enable GitHub Actions, workflows are able to run actions and reusable workflows located within your repository and any other public or internal repository. You can disable GitHub Actions for all repositories in your organization. When you disable GitHub Actions, no workflows run in your repository.

Alternatively, you can enable GitHub Actions for all repositories in your organization but limit the actions and reusable workflows a workflow can run.

Managing GitHub Actions permissions for your organization

You can choose to disable GitHub Actions for all repositories in your organization, or only allow specific repositories. You can also limit the use of public actions and reusable workflows, so that people can only use local actions and reusable workflows that exist in your enterprise.

1. In the upper-right corner of GitHub, select your profile photo, then click Your organizations.

2. Next to the organization, click Settings.

3. In the left sidebar, click Actions, then click General.

4. Under "Policies", select an option.

   If you choose Allow enterprise, and select non-enterprise, actions and reusable workflows, actions and reusable workflows within your enterprise are allowed, and there are additional options for allowing other specific actions and reusable workflows. For more information, see Allowing select actions and reusable workflows to run.

   When you allow actions and reusable workflows from only in your enterprise, the policy blocks all access to actions authored by GitHub. For example, the actions/checkout action would not be accessible.

5. Click Save.

Allowing select actions and reusable workflows to run

When you choose Allow enterprise, and select non-enterprise, actions and reusable workflows, local actions and reusable workflows are allowed, and there are additional options for allowing other specific actions and reusable workflows:

• Allow actions created by GitHub: You can allow all actions created by GitHub to be used by workflows. Actions created by GitHub are located in the actions and github organizations. For more information, see the actions and github organizations.

• Allow Marketplace actions by verified creators: You can allow all GitHub Marketplace actions created by verified creators to be used by workflows. When GitHub has verified the creator of the action as a partner organization, the badge is displayed next to the action in GitHub Marketplace.

• Allow specified actions and reusable workflows: You can restrict workflows to use actions and reusable workflows in specific organizations and repositories. Specified actions cannot be set to more than 1000.

  To restrict access to specific tags or commit SHAs of an action or reusable workflow, use the same syntax used in the workflow to select the action or reusable workflow.

  • For an action, the syntax is OWNER/REPOSITORY@TAG-OR-SHA. For example, use actions/javascript-action@v1.0.1 to select a tag or actions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f to select a SHA. For more information, see Using pre-written building blocks in your workflow.
  • For a reusable workflow, the syntax is OWNER/REPOSITORY/PATH/FILENAME@TAG-OR-SHA. For example, octo-org/another-repo/.github/workflows/workflow.yml@v1. For more information, see Reusing workflows.

  You can use the * wildcard character to match patterns. For example, to allow all actions and reusable workflows in organizations that start with space-org, you can specify space-org*/*. To allow all actions and reusable workflows in repositories that start with octocat, you can use */octocat**@*. For more information about using the * wildcard, see Workflow syntax for GitHub Actions.

  Use , to separate patterns. For example, to allow octocat and octokit, you can specify octocat/*, octokit/*.

  Observação

  For GitHub Free, GitHub Pro, GitHub Free for organizations, or GitHub Team plans, the Allow specified actions and reusable workflows option is only available in public repositories.

This procedure demonstrates how to add specific actions and reusable workflows to the allow list.

1. In the upper-right corner of GitHub, select your profile photo, then click Your organizations.
2. Next to the organization, click Settings.
3. In the left sidebar, click Actions, then click General.
4. Under "Policies", select Allow enterprise, and select non-enterprise, actions and reusable workflows and add your required actions and reusable workflows to the list.
5. Click Save.

Limiting the use of self-hosted runners

There is no guarantee that self-hosted runners for GitHub will be hosted on ephemeral, clean virtual machines. As a result, they may be compromised by untrusted code in a workflow.

Similarly, anyone who can fork the repository and open a pull request (generally those with read access to the repository) can compromise the self-hosted runner environment, including gaining access to secrets and the GITHUB_TOKEN which, depending on its settings, can grant write access to the repository. Although workflows can control access to environment secrets by using environments and required reviews, these workflows are not run in an isolated environment and are still susceptible to the same risks when run on a self-hosted runner.

For these and other reasons, you may decide to prevent people creating self-hosted runners at the repository level.

If a repository already has self-hosted runners when you disable their use, these will be listed with the status "Disabled" and they will not be assigned any new workflow jobs.

1. In the upper-right corner of GitHub, select your profile photo, then click Your organizations.
2. Next to the organization, click Settings.
3. In the left sidebar, click Actions, then click General.
4. Under "Runners," use the dropdown menu to choose your preferred setting:
   • All repositories - self-hosted runners can be used for any repository in your organization.
   • Selected repositories - self-hosted runners can only be used for the repositories you select.
   • Disabled - self-hosted runners cannot be created at the repository level.
5. If you choose Selected repositories:
   1. Click .
   2. Select the check boxes for the repositories for which you want to allow self-hosted runners.
   3. Click Select repositories.

Configuring required approval for workflows from public forks

Anyone can fork a public repository, and then submit a pull request that proposes changes to the repository's GitHub Actions workflows. Although workflows from forks do not have access to sensitive data such as secrets, they can be an annoyance for maintainers if they are modified for abusive purposes.

To help prevent this, workflows on pull requests to public repositories from some outside contributors will not run automatically, and might need to be approved first. Depending on the "Approval for running fork pull request workflows from contributors" setting, workflows on pull requests to public repositories will not run automatically and may need approval if:

• The pull request is created by a user that requires approvals based on the selected policy.
• The pull request event is triggered by a user that requires approvals based on the selected policy.

By default, all first-time contributors require approval to run workflows.

Workflows triggered by pull_request_target events are run in the context of the base branch. Since the base branch is considered trusted, workflows triggered by these events will always run, regardless of approval settings. For more information about the pull_request_target event, see Events that trigger workflows.

You can configure this behavior for an organization using the procedure below. Modifying this setting overrides the configuration set at the enterprise level.

1. In the upper-right corner of GitHub, select your profile photo, then click Your organizations.

2. Next to the organization, click Settings.

3. In the left sidebar, click Actions, then click General.

4. Under Approval for running fork pull request workflows from contributors, choose which subset of users will require approval before running workflows on their pull requests. Both the pull request author and the actor of the pull request event triggering the workflow will be checked to determine if approval is required. If approval is required, a user with write access to the repository must approve the pull request workflow to be run. See Approving workflow runs from public forks.

   Aviso

   When requiring approvals only for first-time contributors (the first two settings), a user that has had any commit or pull request merged into the repository will not require approval. A malicious user could meet this requirement by getting a simple typo or other innocuous change accepted by a maintainer, either as part of a pull request they have authored or as part of another user's pull request.

   • Require approval for first-time contributors who are new to GitHub. Only users who are both new on GitHub and who have never had a commit or pull request merged into this repository will require approval to run workflows.
   • Require approval for first-time contributors. Only users who have never had a commit or pull request merged into this repository will require approval to run workflows.
   • Require approval for all external contributors All users that are not a member or owner of this repository and not a member of the organization will require approval to run workflows.

5. Click Save to apply the settings.

For more information about approving workflow runs that this policy applies to, see Approving workflow runs from public forks.

Enabling workflows for private repository forks

If you rely on using forks of your private repositories, you can configure policies that control how users can run workflows on pull_request events. Available to private and internal repositories only, you can configure these policy settings for enterprises, organizations, or repositories.

If a policy is disabled for an enterprise, it cannot be enabled for organizations. If a policy is disabled for an organization, it cannot be enabled for repositories. If an organization enables a policy, the policy can be disabled for individual repositories.

• Run workflows from fork pull requests - Allows users to run workflows from fork pull requests, using a GITHUB_TOKEN with read-only permission, and with no access to secrets.
• Send write tokens to workflows from pull requests - Allows pull requests from forks to use a GITHUB_TOKEN with write permission.
• Send secrets to workflows from pull requests - Makes all secrets available to the pull request.
• Require approval for fork pull request workflows - Workflow runs on pull requests from collaborators without write permission will require approval from someone with write permission before they will run.

Configuring the private fork policy for an organization

1. In the upper-right corner of GitHub, select your profile photo, then click Your organizations.
2. Next to the organization, click Settings.
3. In the left sidebar, click Actions, then click General.
4. Under Fork pull request workflows, select your options.
5. Click Save to apply the settings.

Setting the permissions of the GITHUB_TOKEN for your organization

You can set the default permissions granted to the GITHUB_TOKEN. For more information about the GITHUB_TOKEN, see Automatic token authentication. You can choose a restricted set of permissions as the default, or apply permissive settings.

You can set the default permissions for the GITHUB_TOKEN in the settings for your organization or your repositories. If you select a restrictive option as the default in your organization settings, the same option is selected in the settings for repositories within your organization, and the permissive option is disabled. If your organization belongs to a GitHub Enterprise account and a more restrictive default has been selected in the enterprise settings, you won't be able to select the more permissive default in your organization settings.

Anyone with write access to a repository can modify the permissions granted to the GITHUB_TOKEN, adding or removing access as required, by editing the permissions key in the workflow file. For more information, see permissions.

Configuring the default GITHUB_TOKEN permissions

By default, when you create a new organization, the setting is inherited from what is configured in the enterprise settings.

1. In the top right corner of GitHub, click your profile photo, then click Your profile.

   

2. In the upper-right corner of GitHub, select your profile photo, then click Your organizations.

3. Next to the organization, click Settings.

4. In the left sidebar, click Actions, then click General.

5. Under "Workflow permissions", choose whether you want the GITHUB_TOKEN to have read and write access for all permissions (the permissive setting), or just read access for the contents and packages permissions (the restricted setting).

6. Click Save to apply the settings.

Preventing GitHub Actions from creating or approving pull requests

You can choose to allow or prevent GitHub Actions workflows from creating or approving pull requests.

By default, when you create a new organization, workflows are not allowed to create or approve pull requests.

1. In the top right corner of GitHub, click your profile photo, then click Your profile.

   

2. In the upper-right corner of GitHub, select your profile photo, then click Your organizations.

3. Next to the organization, click Settings.

4. In the left sidebar, click Actions, then click General.

5. Under "Workflow permissions", use the Allow GitHub Actions to create and approve pull requests setting to configure whether GITHUB_TOKEN can create and approve pull requests.

6. Click Save to apply the settings.

Managing GitHub Actions cache storage for your organization

Organization administrators can view GitHub Actions cache storage for all repositories in the organization.

Viewing GitHub Actions cache storage by repository

For each repository in your organization, you can see how much cache storage a repository is using, the number of active caches, and if a repository is near the total cache size limit. For more information about the cache usage and eviction process, see Caching dependencies to speed up workflows.

1. In the top right corner of GitHub, click your profile photo, then click Your profile.

   

2. In the upper-right corner of GitHub, select your profile photo, then click Your organizations.

3. Next to the organization, click Settings.

4. In the left sidebar, click Actions, then click Caches.

5. Review the list of repositories for information about their GitHub Actions caches. You can click on a repository name to see more detail about the repository's caches.