Security: How to prevent malicious workflow operations?

[alukach]

I am exploring using this project to assist us in implementing continuous deployment in a secured AWS environment. In general, the administrators of our AWS environment would prefer to not grant long-lasting widely-scoped AWS credentials to Github. It seemed that this project could help us avoid that by hosting our runner within our secured AWS environment and then we can manage the widely-scoped AWS credentials within the environment. However, my concern is that anyone with the ability to make a pull-request on our (private) Github repos would be able to customize the Github Actions workflows to run any arbitrary commands. For example, one could make a PR to change our workflow from triggering on PR merge to triggering on push and changing the instructions from deploying our infrastructure to deleting our infrastructure.

Idea 1: Reviewing deployments

One solution might be to take advantage of Github's feature for reviewing deployments, however that is only available on Github Enterprise (which we do not use) or public repos which is ill-advised. Additionally, I'm not positive that this would solve the vulnerability where a user could make a PR with a modified Github Actions workflow.

Idea 2: Moving configuration out of the repository

It seems like the only other solution is where we take CD configuration out of the Github repo and place it in a more secured location. One example of this would be to move deployment instructions to AWS CodeDeploy. Another example would be to hardcode some guard-rails into our self-hosted runner. We already have this ability to some degree with the repository_white_list configuration.

Filter by event types

It would be nice if we could specify that the self-hosted runner would only handle workflows triggered from merged pull-requests. This way, we could utilize Github's features for branch protection to enforce that a repository admin has OK'd the code change. To safely achieve this, I believe this project would need some new features:

1. Require that the Webhook Event was triggered from a merged PR.
2. The above may not be enough, as we wouldn't want to run commands on merges into unprotected branches. Therefore, we would want to require that the branch is a protected branch. Alternatively we could have a white-list of branches to use (this feels like it would be more difficult to administer for runners that monitor many repositories).

Filter by Github username

Another idea would be to only listen to events triggered by known trusted users. I'm honestly not sure what the best way to achieve this would be, but I imagine another optional array that the webhook lambda could filter on.

---

I'd love to hear ideas about how to best handle securing executions of workflows with roles that require wide-scoped privileges.

[edkeeble]

A thought on filtering by event types: I believe we would need to handle this in both the webhook lambda and the runner, since we don't have a way to prevent Github from creating the unwanted workflows internally. This could lead to an undesirable situation where workflows that don't match our filters sit idle until they either timeout or are manually cancelled.