We’ve been pursuing two different strategies.

The first mechanism is to have github actions spin up a dedicated runner, run the CI, and then turn off that runner. This approach is fairly simple, and should be pretty quick to implement. It works works by giving github appropriate AWS credentials. Because github only shares credentials with the primary org (no forks), this is reasonably secure. But, it cannot work on non-osquery forks. Still, having a test run post merge is hugely valuable. This is represented by https://github.com/osquery/osquery/pull/7014 While not merged, this is currently running, and feels pretty close.

The second approach is to keep standing github runners around read to process jobs. Because these runners are running public code, we need to take several steps to protect them. They have somewhat complicated permissions scheme where they start with enough to configure them, then they drop permission. This work is represented by https://github.com/osquery/infrastructure/pull/7 and is less far along than the first approach.

Happy to answer any questions!

What's everyone's preference?

I think we’ll see the first approach (runners spun up on branches in the osquery org) and while we work on suitable isolation for the other

The second approach, is a persistent hosted ARM-based CI runner that anyone can run jobs on? Yea I don't know if that's advisable. I acknowledge the benefit —anyone can run the CI jobs even from their forks— but, maybe for this we should just wait for GitHub Actions to provide a runner.

Regarding #2, there are definite security concerns, however, @David Gibb from the AWS side is happy to put together a secure environment where we could test this.

I think I could probably create some kind of readonly role on the AWS accounts if that would be interesting