How would you keep production credentials unreachable from GitHub Actions runs on fork pull requests?

## The threat, stated precisely A fork pull request is arbitrary code from someone with no access to your repository, proposed for execution on your CI. If that execution has credentials in its environment, the contributor has those credentials — a build script, a test, a dependency's install hook, or a modified workflow step can print, upload, or use them. Masking does not help, because the attacker controls the encoding. ## Layer 1: keep the default GitHub already makes fork pull-request runs safe by default: no secrets, a read-only `GITHUB_TOKEN`, and no access to environment-scoped values. The right posture is to leave that intact and design pipelines that do not need to break it. Most CI genuinely does not: compiling, linting, and unit tests need no credential. If a test needs a service, prefer an ephemeral container in the job over a shared account. ## Layer 2: understand what breaks it Three workarounds account for nearly all real incidents. **`pull_request_target`.** This trigger exists so a workflow can label or comment on a fork pull request; it runs the workflow file from the **base** branch, in the base repository's context, with secrets and a writable token. That is safe only while the job does not execute head code. Adding `actions/checkout` with `ref: ${{ github.event.pull_request.head.sha }}` and then running a build hands full credentials to the contributor. If you use this trigger, keep the job to metadata operations, never check out the head, and never run a script or install dependencies from it. **Self-hosted runners on public repositories.** A fork pull request that runs on your own hardware executes untrusted code inside your network, with whatever the machine can reach and whatever previous jobs left on disk. Public repositories should use hosted runners; if self-hosted is unavoidable, make them ephemeral and network-isolated. **Unpinned third-party actions.** A mutable tag can be repointed at new code, and every action in the job can read everything the job holds. Pin to full commit SHAs, especially in any workflow that does hold credentials. ## Layer 3: split the pipeline The durable design separates untrusted execution from privileged execution: 1. A `pull_request`-triggered workflow builds and tests with no secrets, uploading whatever artifacts are needed. 2. A second workflow, triggered by `workflow_run` on the first (or simply running after merge), performs privileged work — publishing, commenting with rich results, deploying a preview. It runs from the base branch's workflow file and consumes the artifact rather than re-executing contributor code. The rule is that the privileged workflow never runs contributor-authored logic. Treat everything crossing the boundary — artifact contents, branch names, pull-request titles — as untrusted data, never as code and never spliced into a shell command via `${{ }}`. ## Layer 4: make privileged jobs approvable Put real credentials on environments. A job that needs the production credential must declare `environment: production`, which means it waits for required reviewers and satisfies the deployment branch policy before it is dispatched — and no secret reaches a runner in the meantime. For cloud access, use OIDC and pin the trust policy's `sub` claim to a ref or environment so that a pull-request context, whose subject takes a different form, cannot assume the role at all. That is a stronger control than any workflow condition, because it is enforced outside the repository. ## Layer 5: verify and constrain - Set restrictive `permissions:` defaults, ideally `contents: read`, so even a workflow without secrets holds a near-powerless token. - Require approval for workflow runs from first-time or outside contributors, so no fork pull-request run starts unwatched. - Restrict which actions may be used at organization level, and review any change to a workflow file in a pull request with the same care as production code. - Rehearse rotation: assume something will leak eventually, and know how long it takes to revoke each credential class. OIDC roles need a policy edit; stored keys need a rotation across every consumer. ## The judgment being tested The interviewer is checking whether you reach for a policy control instead of a clever condition. Answers that hinge on `if: github.event.pull_request.head.repo.full_name == github.repository` are weak: the check is in a file a pull request can propose changing, and it protects one job rather than the credential. Answers that move the credential behind an environment gate or a federated role condition hold regardless of what the workflow file says.