What are policies for GitHub Actions?
Enterprise policies control the options that are available to enterprise members when they use GitHub Actions.
If you don't enforce enterprise policies, organization owners and users with the "Manage organization Actions policies" permission have full control over GitHub Actions for their organizations.
Enforcing policies
-
In the top-right corner of GitHub, click your profile photo, then click Your enterprises.
-
In the list of enterprises, click the enterprise you want to view.
-
On the left side of the page, in the enterprise account sidebar, click Policies.
-
Under " Policies", click Actions.
-
After you configure each policy, click Save.
For more information about each section of the "Policies" page, continue reading.
Policies
In the "Policies" section, you can control which organizations within your enterprise can use GitHub Actions, with the following options:
- Enable GitHub Actions for all organizations
- Enable GitHub Actions for specific organizations
- Disable GitHub Actions for all organizations
You can also limit the use of public actions and reusable workflows, with the following options:
- Allow all actions and reusable workflows: Any action or reusable workflow can be used, regardless of who authored it or where it is defined.
- Allow enterprise actions and reusable workflows: Only actions and reusable workflows defined in a repository within the enterprise can be used. Blocks all access to actions authored by GitHub, such as the
actions/checkout
action. - Allow enterprise, and select non-enterprise, actions and reusable workflows: Any action or reusable workflow defined in a repository within the enterprise can be used, plus any action or reusable workflow that matches criteria you specify.
Allow enterprise, and select non-enterprise, actions and reusable workflows
If you choose this option, actions and reusable workflows within your enterprise are allowed, and you'll have the following options for allowing other actions and reusable workflows:
- Allow actions created by GitHub: Allows all actions created by GitHub, located in the
actions
andgithub
organizations. - Allow Marketplace actions by verified creators: Allows all GitHub Marketplace actions created by verified creators, labeled with .
- Allow specified actions and reusable workflows: Allows actions and reusable workflows that you specify. You can specify individual actions and reusable workflows or entire organizations and repositories.
When specifying actions and reusable workflows, use the following syntax:
- 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, useactions/javascript-action@v1.0.1
to select a tag oractions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f
to select a SHA. - 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 an action, the syntax is
- To specify a pattern, use the wildcard character,
*
.- To allow all actions and reusable workflows in organizations that start with
space-org
, usespace-org*/*
. - To allow all actions and reusable workflows in repositories that start with octocat, use
*/octocat**@*
.
- To allow all actions and reusable workflows in organizations that start with
Runners
By default, anyone with admin access to a repository can add a self-hosted runner for the repository, and self-hosted runners come with risks:
- There is no guarantee that self-hosted runners will be hosted on ephemeral, clean virtual machines. As a result, they may be compromised by untrusted code in a workflow.
- Anyone who can fork the repository and open a pull request can compromise the self-hosted runner environment, potentially gaining access to secrets and the
GITHUB_TOKEN
, which may have write access to the repository.
In the "Runners" section, you can mediate these risks by disabling the use of repository-level self-hosted runners.
- Disable for all organizations: Prevents the creation of runners at the repository level.
- Disable in all Enterprise Managed User (EMU) repositories: Prevents the creation of runners for repositories owned by managed user accounts.
Note
When creation of repository-level self-hosted runners is disabled, workflows can still access self-hosted runners at the enterprise or organization level.
Artifact and log retention
By default, artifacts and log files generated by workflows are retained for 90 days. You can change the retention period.
- For public repositories, you can configure a period between 1 and 90 days.
- For private and internal repositories, you can configure a period between 1 and 400 days.
Changes only apply to new artifacts and log files.
Fork pull request workflows from outside collaborators
Anyone can fork a public repository, then submit a pull request to propose changes to the repository's workflows. To prevent abuse, workflows will not run automatically on pull requests created by some contributors.
You can configure which pull requests require approval before they are run.
- Require approval for first-time contributors who are new to GitHub. Requires approval for users who have never committed to the repository and have new GitHub accounts.
- Require approval for first-time contributors. Requires approval for users who have never committed to the repository.
- Require approval for all outside collaborators. Requires approval for all users who are not organization members.
Note
Workflows on the base branch triggered by pull_request_target
events will always run, regardless of approval settings.
Fork pull request workflows in private repositories
You can control how users can run workflows on pull_request
events in private and internal repositories.
- Run workflows from fork pull requests. Users can run workflows from fork pull requests. By default, workflows will use a
GITHUB_TOKEN
with read-only permission, with no access to secrets. - Send write tokens to workflows from pull requests. Workflows will use a
GITHUB_TOKEN
with write permission. - Send secrets to workflows from pull requests. All secrets are available to the pull request.
- Require approval for fork pull request workflows. Workflows on pull requests from collaborators without write permission will require approval from someone with write permission before they will run.
If a policy is enabled for an enterprise, the policy can be selectively disabled in individual organizations or repositories. If a policy is disabled for an enterprise, individual organizations or repositories cannot enable it.
Workflow permissions
In the "Workflow permissions" section, you can set the default permissions granted to the GITHUB_TOKEN
.
- Read and write permissions: By default,
GITHUB_TOKEN
has read and write access for all scopes. - Read repository contents and packages permissions: By default,
GITHUB_TOKEN
has only read access for thecontents
andpackages
scopes. The more permissive setting cannot be chosen as the default for individual organizations or repositories.
Anyone with write access to a repository can still modify the permissions granted to the GITHUB_TOKEN
for a specific workflow, by editing the permissions
key in the workflow file.
Allow GitHub Actions to create and approve pull requests is disabled by default. If you enable this setting, GITHUB_TOKEN
can create and approve pull requests.