8.1 Enterprise & Organization Action Policies

Enterprise & Organization Action Policies

In enterprise environments, managing which GitHub Actions can execute across hundreds of repositories is a vital operational and security responsibility. Unrestricted action execution introduces severe supply chain risks, including secret exfiltration, malicious dependency injection, and unauthorized compute utilization.

GitHub provides a hierarchical governance model spanning the Enterprise Account, Organization, and Repository levels. Understanding how permission tiers operate, how policies are inherited and locked, and how to construct granular action allowlists is a critical domain on the GitHub Actions Certification (GH-200) examination.

---

1. Enterprise Governance Hierarchy & Policy Inheritance

GitHub Actions applies a strict top-down inheritance model across the administrative hierarchy:

┌─────────────────────────────────────────────────────────────┐
│                     Enterprise Account                      │
│  Sets the foundational baseline policy for all organizations│
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼ (Inherits & can only restrict)
┌─────────────────────────────────────────────────────────────┐
│                        Organization                         │
│  Applies org-wide policy; cannot loosen enterprise baseline │
└──────────────────────────────┬──────────────────────────────┘
                               │
                               ▼ (Inherits & can only restrict)
┌─────────────────────────────────────────────────────────────┐
│                         Repository                          │
│  Applies repo-level policy; cannot loosen org baseline      │
└─────────────────────────────────────────────────────────────┘

The Cardinal Rule of Policy Inheritance

The Cardinal Rule: An organization or repository can only make its action policies more restrictive than its parent container—never more permissive.

For example:

• If the Enterprise policy is configured to "Allow actions created by GitHub and verified marketplace creators", an Organization administrator can restrict their organization further to "Allow local actions and reusable workflows only".
• However, that organization administrator cannot select "Allow all actions and reusable workflows", because that would be more permissive than the enterprise baseline.
• If an Enterprise administrator selects "Enforce policy for all organizations (Locked)", organization and repository administrators cannot alter the action permission settings at all.

---

2. GitHub Actions Permission Tiers

Administrators at the Enterprise, Organization, and Repository levels can select from four discrete permission tiers under Settings → Actions → General → Actions permissions:

Tier 1: Disable GitHub Actions

• Disables workflow execution entirely across the container.
• Existing workflows will not trigger on any event (push, pull_request, schedule, manual dispatch).
• The Actions tab in repository navigation is hidden or disabled.
• Used for organizations or repositories that exclusively use external CI/CD systems (e.g., Jenkins, CircleCI) and want to eliminate accidental runner usage.

Tier 2: Allow Local Actions and Reusable Workflows Only

• Workflows can only execute actions and reusable workflows defined within the same repository (e.g., uses: ./.github/actions/my-custom-action) or within repositories owned by the same organization/enterprise.
• Completely blocks all third-party actions from the GitHub Marketplace, including official actions/* repositories (such as actions/checkout or actions/setup-node), unless those repositories have been mirrored internally into the organization.
• Provides high security isolation for air-gapped or strictly internal compliance environments.

Tier 3: Allow Actions Created by GitHub and Verified Marketplace Creators

• Automatically permits all actions created and maintained directly by GitHub under the actions/ and github/ organizations (e.g., actions/checkout, actions/cache, actions/upload-artifact).
• Automatically permits actions published by Verified Creators on the GitHub Marketplace (publishers whose identity has been vetted and verified by GitHub, indicated by a verified creator badge).
• Blocks all actions created by individual community developers or non-verified third parties.

Tier 4: Allow Specified Actions and Reusable Workflows

• Provides the most granular enterprise security control.
• Administrators define an explicit Allowlist using comma-separated or newline-separated pattern-matching strings.
• You can optionally check the box: "Allow actions created by GitHub" to automatically permit all actions/* repositories without listing each one manually.
• You can also check: "Allow Marketplace actions by Marketplace verified creators" alongside custom allowlist patterns.

---

3. Action Allowlist Syntax & Pattern Matching

When configuring "Allow specified actions and reusable workflows", GitHub evaluates workflow uses: statements against the defined pattern rules. An action is permitted if it matches at least one rule in the allowlist.

Pattern Syntax Specification

Practical Enterprise Allowlist Example

# Allow all official GitHub core actions
actions/*
github/*

# Allow official cloud provider partner actions
aws-actions/*
google-github-actions/*
azure/*

# Allow specific verified third-party tools pinned to major versions
docker/setup-buildx-action@v3
docker/build-push-action@v5
snyk/actions/*

# Allow all internal enterprise reusable workflows and composite actions
acme-corp/*

[!WARNING] Pattern Strictness: Specifying actions/* matches any action inside the actions organization at any tag, branch, or SHA. If an enterprise requires cryptographic immutability, administrators should combine allowlists with ruleset commit SHA pinning policies.

---

4. Fork Pull Request Policies & Contributor Protections

Workflows executing on pull_request events from external forks represent a primary attack vector for public and internal open-source repositories. Attackers can submit pull requests containing modified workflow definitions designed to steal CI/CD secrets or execute cryptocurrency miners on hosted compute.

To mitigate this risk, enterprise and organization administrators configure Fork pull request workflow execution policies:

Fork PR Event Triggered
         │
         ▼
Is the author a First-Time Contributor or Outside Collaborator?
   ├── Yes ──► [Approval Gate: Maintainer with Write access must click 'Approve and run']
   │                 │
   │                 ├── Approved ──► Runner executes workflow (Secrets withheld)
   │                 └── Rejected ──► Workflow terminated without execution
   └── No  ──► Workflow executes automatically

Available Fork Approval Settings

1. Require approval for first-time contributors: Workflows created by contributors who have not previously had a pull request merged into the repository require approval from a collaborator with write permissions before running.
2. Require approval for all outside collaborators: Requires maintainer approval for any contributor who is not an explicit member of the repository or organization.
3. Require approval for all fork pull request workflows: Every single pull request originating from a fork requires manual maintainer approval, regardless of contributor history.
4. Run workflows from fork pull requests (Private repositories): By default, workflows do not run on pull requests from private forks. Admins can enable this setting, and specify whether pull_request runs from forks receive read-only tokens and masked secrets.

Secret Isolation for Fork Workflows

• For pull_request events originating from a fork, GitHub Actions never passes repository secrets to the runner environment.
• The default GITHUB_TOKEN provided to fork pull request workflows has strictly read-only permissions (regardless of organizational default settings).
• If a workflow must access secrets to deploy or comment on a fork pull request, developers must use the pull_request_target event with strict checkout controls, as covered in security chapters.

---

5. Workflow Run Permissions & GITHUB_TOKEN Defaults

At both the Enterprise and Organization levels, administrators enforce baseline permissions for the automatically generated GITHUB_TOKEN:

1. Default GITHUB_TOKEN permissions:
   • Read and write permissions: Grants permissive access across repository contents, packages, issues, and pull requests. (Legacy default; discouraged for enterprise environments).
   • Read repository contents and packages permissions (Least Privilege): Grants read-only access by default. Individual workflows must explicitly declare write permissions using the top-level or job-level permissions: block.
2. Fork pull request workflow approvals: Administrators can globally enforce whether fork workflows are permitted to create or approve pull requests (Allow GitHub Actions to create and approve pull requests).