Application de stratégies pour GitHub Actions dans votre entreprise

Vous pouvez appliquer des stratégies pour gérer la façon dont GitHub Actions peut être utilisé au sien de votre entreprise.

Qui peut utiliser cette fonctionnalité ?

Enterprise owners

Dans cet article

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

  1. In the top-right corner of GitHub, click your profile photo.
  2. Depending on your environment, click Your enterprise, or click Your enterprises then click the enterprise you want to view.
  3. On the left side of the page, in the enterprise account sidebar, click Policies.
  4. Under " Policies", click Actions.
  5. 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 and github 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, use actions/javascript-action@v1.0.1 to select a tag or actions/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.
  • To specify a pattern, use the wildcard character, *.
    • To allow all actions and reusable workflows in organizations that start with space-org, use space-org*/*.
    • To allow all actions and reusable workflows 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.

  • 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 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.