Overview of JIT GitHub Runners on AWS Fargate

In a past series of articles, I outlined an approach for implementing containerized, self-hosted ephemeral runners on AWS ECS/EC2, with Amazon cluster auto scaling enabled. Maintenance of the final infrastructure (e.g., administration of EC2 instances), would be tasks primarily owned by site administrators.

In this new series, we aim to leverage off the existing infrastructure/resources, and add support for GitHub just-in-time (JIT) runners on AWS Fargate.

What are GitHub self-hosted just-in-time (JIT) Runners?

JIT self-hosted runners are also classified as ephemeral—designed to run a single job before being automatically removed from the associated repository, organization, or enterprise.

The guidelines on security hardening for GitHub actions, promote their usage as best practice for a number of reasons, including improved registration security.

Provisioning a JIT runner involves:

• Generating a configuration by calling the respective GitHub Rest API endpoint
• Executing the following command, and passing the configuration via parameter --jitconfig

$ ./run.sh --jitconfig ${encoded_jit_config}

Points to Consider for JIT Runners and Fargate

Fargate is a serverless platform, owned and managed by Amazon AWS. Depending on the use case for a runner, this may introduce an inherent paradox. For example, root/su access to Fargate EC2 instances is not supported, which would rule out options such as privileged containers, or Docker in Docker.

Other factors worth taking into consideration include application processing and workload requirements.

Solution Architecture

The solution architecture to support our objective is made up of the following components.

Before moving on, the following prerequisite activities have already been covered, and as such, will be considered assumed knowledge.

• GitHub Self-hosted Runner Registration Token
• EventBus and Schema Discoverer
• Lambda Function URL
• GitHub Webhook

They cover the setup tasks required to implement the GitHub to EventBridge integration in order for workflow_job events to start flowing through to an established event bus. This is the point where this series picks up from.