Secrets Not Available in Pull Request Workflows

[bright8r]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

Hi, I'm Kiran, and I work at Bright Steel Centre. I noticed that secrets are not accessible when workflows are triggered from forked repositories. Is there a secure way to handle secrets for external contributions?

[Yojitkataria]

GitHub intentionally does not expose repository secrets to workflows triggered from forked repositories.
This is by design to prevent untrusted code from exfiltrating secrets.

There is no safe way to directly pass secrets to fork-based pull_request workflows.

The 100% correct and secure pattern is to separate untrusted code execution from secret usage.

---

🔒 Secure Patterns

1. Use pull_request for untrusted code (NO secrets)

Run linting, build, and tests only.

on:
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm test

This is safe because no secrets are exposed.

---

2. Use workflow_run for trusted execution (WITH secrets)

After PR checks pass, run a second workflow triggered from the base repository, where secrets are available.

on:
  workflow_run:
    workflows: ["PR Tests"]
    types: [completed]

jobs:
  deploy:
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh
        env:
          API_KEY: ${{ secrets.API_KEY }}

This ensures:

• Forked code runs without secrets
• Secrets only run in trusted context

---

3. Alternative: Manual approval with environments (Highly recommended)

Use environment protection rules with required reviewers.

jobs:
  deploy:
    environment: production

Secrets in production environment are only available after maintainer approval.

---

⚠️ Avoid These (Unsafe)

❌ Using pull_request_target + checking out fork code
❌ Enabling "Send secrets to forks"
❌ Running deployment inside fork PR workflow
❌ Passing secrets via artifacts

These can leak secrets.

---

✅ Best Practice Summary

• Use pull_request → build/test only (no secrets)
• Use workflow_run or manual approval → privileged jobs
• Use environment protection for approval gates
• Never expose secrets to forked code

This is the official and secure GitHub-recommended architecture for handling secrets with external contributors.

[Gecko51]

This is a deliberate security restriction. pull_request workflows from forks run with read-only permissions and no access to secrets, specifically to prevent a malicious contributor from exfiltrating your credentials with something like echo $SECRET in a workflow step.

There are two solid patterns depending on your use case:

Pattern 1: workflow_run (safest for external contributions)

Create a separate workflow that triggers after your PR checks complete. It runs in the context of the base repo and has full access to secrets:

on:
  workflow_run:
    workflows: ["CI"]
    types: [completed]

jobs:
  use-secrets:
    runs-on: ubuntu-latest
    if: github.event.workflow_run.event == 'pull_request'
    steps:
      - uses: actions/download-artifact@v4
        with:
          run-id: ${{ github.event.workflow_run.id }}
          github-token: ${{ secrets.GITHUB_TOKEN }}
      - name: Deploy preview
        env:
          API_KEY: ${{ secrets.API_KEY }}
        run: ./deploy.sh

The PR workflow builds and uploads artifacts, the workflow_run workflow picks them up and does the secret-dependent work. The untrusted code never runs in the same context as your secrets.

Pattern 2: pull_request_target

This event runs in the base repo context and has secrets, but be careful: never check out the PR's code (ref: ${{ github.event.pull_request.head.sha }}) in the same job that uses secrets. If you need to run code from the PR, do it in a separate job with no secret access, then pass results as artifacts to a secrets-only job.

For most use cases involving external contributors, workflow_run is the cleaner and safer choice. pull_request_target is useful when you specifically need the PR metadata (labels, title, etc.) alongside secrets, like for auto-labeling or comment-posting workflows.