https://github.com/osquery/osquery logo
Join Slack
Powered by
<@U6EFFT5FG> <@U7QP20JQH>, <@U01S6SPG1M0>, and I h...
# arm-architecture
p
@alessandrogario @seph, @David Gibb, and I had a discussion recently and due to security concerns with GitHub Actions we believe the current model will persist. Additionally, the lack of broader control (job start, job queue, etc) via GH APIs is another challenge today. However, based on the above change we can take another look at this.
a
What are the concerns exactly? I would have liked to store the credentials elsewhere
and from the osquery org use a request to start an instance for us; this would ensure that at the very worst a bad PR would never be able to steal the credentials
More specifically, I wanted to know what were the added difficulties compared to the built-in GitHub Actions runners
s
I don’t have this well written. So an ugly braindump: github hosted stuff has some additional steps around minting a token for the runner, running, and then destroying. But those hooks aren’t really exposed for the self hosted ones. You can mint tokens, yes. But you cannot ensure a runner only runs once.
You can kinda, in that there are some wholly unsupported command line arguments that they left behind due to sloppy code. but thre’s some large github issues where they talk about how that can cause the servers to get confused and dispatch to dead runners
The crux of it. is that there is no github supported way to have a runner be ephemeral, or run only once.
There are ways to hack it. and ways to reduce the timing window where things might go badly, but it just doesn’t feel good. And it feels like we’re fighting github for it.
I think it’s clear this isn’t something they’re going to support. They’ve had an internal PR languishing for a year.
a
what are exactly the security concerns we inherit from the self-hosted runners that are not present in built-in GitHub runners?
(other than the AWS credentials, that we can move outside the org)
s
There is no way to ensure the hosts state is reset between test runs.
a
And what is the reason we can't use the codebuild alternative?
I thought we were going to move to it but it seems like that is no longer the case
s
Oh, that’s the current plan — use the AWS codebuild for the arm builds.
I don’t think GitHub’s changes really address our concerns
a
I may have read it wrong, I thought 'the current model will persist' meant we would have kept what we have now
s
Yeah, I’m not sure I agree.
a
the GitHub changes are not that useful IMHO, one could just make a legit PR first and then a rogue PR next
s
Exactly.
a
once their name has been allowlisted
s
They’re targetting simple drive by crypto mining. Where the vulnerability we see requires a careful attack.
a
I'm still in favor of moving to codebuild if it works better
✅ 1
s
I expect to move to codebuild, just no time.
👍 2
And the current stop gap is okay
(last week was school vacation, so it was rough)
p
If we want to move to CodeBuild...we can help put together some example code that you all can take a look at
Candidly, really disappointed that the GitHub APIs aren't more flexible so we could do this with Self Hosted Runners 😞
m
16 Views
Open in Slack
PreviousNext
Powered by