3

We have a function code in our organization's GitHub repository that is supposed to get compiled and deployed in an AWS Lambda Function and give emit an expected output. We are trying to implement this as an integration test in CI/CD pipeline using GitHub actions. We want this action to run each time a new PR is created to ensure that included code changes do not lead to any regression test failures.

This is how the GitHub action is expected to run:

  1. Use aws-actions/configure-aws-credentials to assume a role backed by OIDC connector behind the scenes, where ROLE_ARN is passed as a secret.
  2. Build code and update the AWS Lambda Function with the latest code
  3. Invoke Lambda Function
  4. Compare output from Step 3 with a pre-determined expected output
  5. Pass or fail the integration test based on comparison in Step 4

(Ideally, we would want to extend this to also create a new Lambda function with auto-generated name on every execution and clean it up after the execution is complete, but that's not relevant to the problem statement.)

We are aware that GitHub best practices recommend that organization secrets should not be shared on a forked PR as it opens up possibility of threats by bad actors using script injection attack. (Reference - Security hardening for GitHub Actions) Even if we set up an action, the secrets are not initialized in a fork-origin PR workflow.

We need to know, then, what are the recommended ways to implement the equivalent of what we are trying to achieve here? Since this might be one of the most common use cases encountered by the community.

We also tried seeing if environment secrets behave differently than repository secrets, but turns out for a fork-origin PR none of the secrets (including env secrets) get passed.

Why can't we have a manual approval-backed workflow (similar to environments) where an approver will first ensure if the corresponding GitHub action workflow isn't changed for dangerous actions (like an injection) and only then run the integration test?

Update 3/6: Turns out there is another downside with the fork-origin PRs apart from just passing secrets, the permission for id-token cannot be set to write, the most it could be set to is read. (Reference - Automatic token authentication)

Akshay Rane
  • 403
  • 4
  • 13

1 Answers1

1

If you are using private repositories with forks, you can enable the option to "Send write tokens to workflows from pull requests" which allows pull requests from forks to use a GITHUB_TOKEN with write permission. Your organization might need to enable this centrally to allow usage if they have not done so yet.

You should also "Require approval for fork pull request workflows" to ensure workflow runs on pull requests from collaborators without write permission will be reviewed and approved from someone with write permission before they run.

timmeinerzhagen
  • 772
  • 7
  • 10