elink21 commented on PR #22703:
URL: https://github.com/apache/beam/pull/22703#issuecomment-1226589948
Below we will describe the different possible scenarios we have found for
the Github actions features/restrictions and repo configurations. Please feel
free to add your comments and questions.
**Scenario 1**: `pull_request_target` for workflows with “**Read repository
contents permissions**“ and “**Require approval from all outside
collaborators**” at Beam repo level
- Pros
- Avoid updating and injecting insecure code to the workflow as it will
always run the master workflow
- Workflows must have the checkout reference to the PR in order to run the
changes in the code (outside of .github/workflows/*)
- Seed job will be emulated using the Approve and Run built in feature of
GH Actions and updating the event trigger to `pull_request;` no modifications
would be allowed either for new or existent jobs unless a committer explicitly
approves the job from UI.
- The “Read repository contents permissions” option will give ONLY the
content and metadata read permissions by default. If the workflow needs another
permission, it will need to be explicitly specified.
- Workflows with `pull_request_target` directive are always executed in
the master context, and can’t be modified externally unless someone with admin
rights exposes secrets directly inside the master workflow (as environment
variables i.e), those secrets shouldn’t be accessible from the workflow
executions.
- Cons
- Repository Secrets can be accessed in the src code if the secret is
explicitly passed to it as an environment variable. Committers/reviewers must
reject passing secrets to the code if the workflow is vulnerable to
modifications or can be triggered by unsafe events.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
