Secure CI for GitLab with Firecracker microVMs
Learn how actuated for GitLab CI can help you secure your CI/CD pipelines with Firecracker.
We started building actuated for GitHub Actions because we at OpenFaaS Ltd had a need for: unmetered CI minutes, faster & more powerful x86 machines, native Arm builds and low maintenance CI builds.
And most importantly, we needed it to be low-maintenance, and securely isolated.
None of the solutions at the time could satisfy all of those requirements, and even today with GitHub adopting the community-based Kubernetes controller to run CI in Pods, there is still a lot lacking.
As we've gained more experience with customers who largely had the same needs as we did for GitHub Actions, we started to hear more and more from GitLab CI users. From large enterprise companies who are concerned about the security risks of running CI with privileged Docker containers, Docker socket binding (from the host!) or the flakey nature and slow speed of VFS with Docker In Docker (DIND).
The GitLab docs have a stark warning about using both of these approaches. It was no surprise that when a consultant at Thoughtworks reached out to me, he listed off the pain points and concerns that we'd set out to solve for GitHub Actions.
At KubeCon, I also spoke to several developers who worked at Deutsche Telekom who had numerous frustrations with the user-experience and management overhead of the Kubernetes executor.
So with growing interest from customers, we built a solution for GitLab CI - just like we did for GitHub Actions. We're excited to share it with you today in tech preview.
For every build that requires a runner, we will schedule and boot a complete system with Firecracker using Linux KVM for secure isolation. After the job is completed, the VM will be destroyed and removed from the GitLab instance.
actuated for GitLab is for self-hosted GitLab instances, whether hosted on-premises or on the public cloud.
If you'd like to use it or find out more, please apply here: Sign-up for the Actuated pilot
Secure CI with Firecracker microVMs
Firecracker is the open-source technology that provides isolation between tenants on certain AWS products like Lambda and Fargate. There's a growing number of cloud native solutions evolving around Firecracker, and we believe that it's the only way to run CI/CD securely.
Firecracker is a virtual machine monitor (VMM) that uses the Linux Kernel-based Virtual Machine (KVM) to create and manage microVMs. It's lightweight, fast, and most importantly, provides proper isolation, which anything based upon Docker cannot.
There are no horrible Kernel tricks or workarounds to be able to use user namespaces, no need to change your tooling from what developers love - Docker, to Kaninko or Buildah or similar.
You'll get sudo
, plus a fresh Docker engine in every VM, booted up with systemd, so things like Kubernetes work out of the box, if you need them for end to end testing (as so many of us do these days).
You can learn the differences between VMs, containers and microVMs like Firecracker in my video from Cloud Native Rejekts at KubeCon Amsterdam:
Many people have also told me that they learned how to use Firecracker from my webinar last year with Richard Case: A cracking time: Exploring Firecracker & MicroVMs.
Let's see it then
Here's a video demo of the tech preview we have available for customers today.
You'll see that when I create a commit in our self-hosted copy of GitLab Enterprise, within 1 second a microVM is booting up and running the CI job.
Shortly after that the VM is destroyed which means there are absolutely no side-effects or any chance of leakage between jobs.
Here's a later demo of three jobs within a single pipeline, all set to run in parallel.
Here's 3x @GitLab CI jobs running in parallel within the same Pipeline demoed by @alexellisuk
— actuated (@selfactuated) June 13, 2023
All in their own ephemeral VM powered by Firecracker 🔥#cicd #secure #isolation #microvm #baremetal pic.twitter.com/fe5HaxMsGB
Everything's completed before I have a chance to even open the logs in the UI of GitLab.
Wrapping up
actuated for GitLab is for self-hosted GitLab instances, whether hosted on-premises or on the public cloud.
Here's what we bring to the table:
- 🚀 Faster x86 builds
- 🚀 Secure isolation with Firecracker microVMs
- 🚀 Native Arm builds that can actually finish
- 🚀 Fixed-costs & less management
- 🚀 Insights into CI usage across your organisation
Runners are registered and running a job in a dedicated VM within less than one second. Our scheduler can pack in jobs across a fleet of servers, they just need to have KVM available.
If you think your automation for runners could be improved, or work with customers who need faster builds, better isolation or Arm support, get in touch with us.
- Sign-up for the Actuated pilot
- Browse the docs and FAQ for actuated for GitHub Actions
- Read customer testimonials
You can follow @selfactuated on Twitter, or find me there too to keep an eye on what we're building.