Is there a way to force Github actions use main branch workflow files in a pull request trigger from a fork?

Question

I have a question using github actions with a fork model.

I work with a fork model, where forked repository needs to be checked by CI workflows in a pull requests from the fork back to base repository . The CI workflows needs some secret from the base repository.

Current setup:

1. Base Repository/main branch/.github/workflows/correct workflow files.

2. Forked Repository/main branch/.github/workflows/maliciously modified files to reveal secrets.

3. Action settings in base repository:

   • Run workflows from fork pull requests [yes]
   • Send write tokens to workflows from fork pull requests [no]
   • Send secrets to workflows form fork pull requests [yes]

Observed Behaviors/Q:

1. I can create a pull request from forked main branch -> base main branch
2. The request triggers workflow runs, using files from the FORKED repository. This is a problem because someone can fork the branch and add workflow to reveal secrets.
3. The aws-actions/configure-aws-credentials inside a workflow can log in with AWS. This is a problem because this action requires permissions: id-token: write . From what I understand, pull requests from forks should not grant any write permissions to workflows. I am concerned about security here as well.

Hopeful behavior:

What I want to achieve is, still allowing pull requests from forked repos to trigger CI workflows, but using files from the base repo instead of the forked repo. Is this possible in anyways? If not, any remedies?

Also want to check my understanding about the supposedly read only permission granted to forked pull requests. Why the id-token:write permission seems to work? Is it true that the explicit permission declaration in workflow files can override the fork pull request limitation?

Apologize if I misunderstand important concepts, first time workflow user.

Reference: prevent PWN attacks

Answer 1

I'm unable to provide a solution to protect general credentials, however I can propose a workaround for AWS-specific credentials.

OpenID Connect

You can create an IAM role that OpenID enabled, and trust github action assume it. This was accomplished by a variety of our github actions.

You can find more detail in github's docs.

https://docs.github.com/cn/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services