Module 9 Lesson 5: Hardening the Runner
Protect the muscle. Learn how to secure your private GitLab Runners to prevent container breakout and ensure your secrets stay on your hardware.
Module 9 Lesson 5: Hardening the Runner
Your Runner is the most powerful server in your company. It has access to your Code, your Secrets, and your Production Servers. If a hacker takes over a runner, they take over your whole company.
1. The "Rootless" Runner
By default, the GitLab Runner agent runs as root. You should configure it to run as a dedicated gitlab-runner user with limited Linux permissions.
2. Preventing "Socket" Attacks
In Docker Module 2, we saw the danger of mounting the /var/run/docker.sock.
- The Risk: A malicious developer could push code that uses that socket to escape their container and take over the Host PC.
- The Fix: Use DinD (Docker-in-Docker) with TLS (Module 7) or Kaniko. Never share the host socket with a project you don't 100% trust.
3. Network Isolation
Your runner should not be able to "Talk" to your internal office database.
- Put your runner on its own VLAN or Private Subnet.
- It only needs two connections: Outbound to GitLab.com (on Port 443) and Outbound to your Production server.
4. One-Time Runners (Ephemeral)
The most secure runner is the one that dies after 1 job.
- The Pattern: Use the Docker Machine or Kubernetes executor.
- It spins up a fresh VM, runs the job, and then DELETES THE VM.
- Any malware left behind by the job is deleted instantly.
5. Summary of Module 9
| Security Layer | Goal |
|---|---|
| Vulnerability Triage | Fix known bugs |
| License Compliance | Avoid legal risk |
| Compliance Pipelines | Force the rules |
| Protected Branches | Guard the main code |
| Hardened Runners | Protect the hardware |
Exercise: The Fortress Test
- Imagine a hacker pushes code to a branch:
rm -rf / --no-preserve-root. If this runs on your Runner, what happens? - Research: What is the "Off-Peak" setting for GitLab Runners, and how does it help save money while maintaining security?
- In your
config.toml, identify theprivileged = truesetting. Why is this necessary for DinD but dangerous for security? - Search: What is gVisor, and how does it add another layer of security to Docker containers?
Summary
You have completed Module 9: Security and Compliance. You are now a "DevSecOps" expert. You know how to build a system that is not only fast and automated but also safe from hackers, lawyers, and human mistakes.
Next Module: Pro efficiency: Module 10: CI/CD Best Practices.