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.

[armorer-labs]

The secure pattern here is really about separating untrusted execution from privileged authority, not only about where the secret string is stored. Fork PRs are the obvious case, but the deeper rule is: low-trust code and high-trust credentials should not share the same execution boundary unless there is an explicit, reviewable handoff.\n\nThat is why workflow_run, environments, and approval gates work so well conceptually. They create a visible transition from "observe or test this untrusted thing" to "allow this trusted context to act."\n\nOnce you frame it that way, the design becomes much easier to reason about than trying to find a clever way to smuggle secrets safely into the first workflow.

[v-coder247]

Hi @bright8r,

We currently do not allow self-promotion, advertising, or solicitation in Community Discussions. We want to make sure there is space for users to ask questions without overwhelming them with other conversations. Thank you for helping us maintain a productive and tidy community for all our members.

For additional guidance, please review our Community on Discussions Code of Conduct and GitHub’s Terms of Service.