Применение политик для GitHub Actions в вашем предприятии

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

1. In the top-right corner of GitHub Enterprise Server, click your profile photo, then click Enterprise settings.

   

2. On the left side of the page, in the enterprise account sidebar, click Policies.

3. Under " Policies", click Actions.

4. 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 and github 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, use actions/javascript-action@v1.0.1 to select a tag or actions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f to select a SHA.
• To specify a pattern, use the wildcard character, *.
  • To allow all actions in organizations that start with space-org, use space-org*/*.
  • To allow all actions in repositories that start with octocat, use */octocat**@*.

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.

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 the contents and packages 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.