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 have full control over GitHub Actions for their organizations.
Enforcing policies
-
In the top-right corner of GitHub Enterprise Server, click your profile photo, then click Enterprise settings.
-
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 , with the following options:
- Allow all actions : Any action can be used, regardless of who authored it or where it is defined.
- Allow enterprise actions : Only actions defined in a repository within the enterprise can be used.
- Allow select actions: Any action defined in a repository within the enterprise can be used, plus any action that matches criteria you specify.
Allow select actions
If you choose this option, actions within your enterprise are allowed, and you'll have the following options for allowing other actions:
-
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 .
Only available if you have GitHub Connect enabled and configured with GitHub Actions. See "Enabling automatic access to GitHub.com actions using GitHub Connect."
-
Allow specified actions: Allows actions that you specify. You can specify individual actions or entire organizations and repositories.
When specifying actions, use the following syntax:
- To restrict access to specific tags or commit SHAs of an action, use the same syntax used in the workflow to select the action.
- 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 an action, the syntax is
- To specify a pattern, use the wildcard character,
*
.- To allow all actions in organizations that start with
space-org
, usespace-org*/*
. - To allow all actions in repositories that start with octocat, use
*/octocat**@*
.
- To allow all actions 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.
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, log, and cache settings
These policies control storage of artifacts, logs, and caches.
Artifact and log retention
By default, artifacts and log files generated by workflows are retained for 90 days. You can change this retention period to anywhere between 1 and 400 days.
Changes only apply to new artifacts and log files.
Maximum and default cache size limits
By default:
- The total cache storage that GitHub Actions uses on the external storage for your GitHub Enterprise Server instance is limited to a maximum of 10 GB per repository.
- The maximum allowed size that can be set for a repository is 25 GB.
If you exceed the limit, GitHub will save the new cache but will begin evicting caches until the total size is less than the repository limit.
You can customize both the default total cache size for each repository and the maximum total cache size allowed for a repository. For example, you might want the default total cache size for each repository to be 5 GB, but also allow administrators to configure a total cache size up to 15 GB for individual repositories.
Organization owners can set a lower total cache size that applies to each repository in their organization. People with admin access to a repository can set a total cache size for their repository up to the maximum cache size allowed by the enterprise or organization policy setting.
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.