Docker Socket Risks in CI/CD and Secure Runner AlternativesDocker Socket Risks in CI/CD and Secure Runner Alternatives
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
René's avatar
René Bon Ćirić
• Oct 4
Mounting docker.sock in CI/CD: Why providing build jobs access to the host Docker daemon gives any pull request total root control over your cloud account.
To build container images inside continuous integration pipelines (GitLab CI, GitHub Actions, Forgejo/Gitea Act Runners), developers need a container runtime. The most common shortcut recommended across internet tutorials is simple: mount the host Docker UNIX socket into the runner container: ``volumes: ["/var/run/docker.sock:/var/run/docker.sock"]``.
In any environment where developers, contractors, or public contributors can submit pull requests, **mounting the host Docker socket is equivalent to granting unauthenticated root access to the entire host**:
1. Trivial Container Breakout: Access to ``docker.sock`` allows any process inside the container to communicate with the host Docker daemon. An attacker submitting a malicious pull request or tainted dependency simply executes: ``docker run -v /:/host -it alpine chroot /host`` In under 2 seconds, the attacker escapes the container, obtaining full root access on the host operating system. 2. Cloud IAM Instance Metadata Theft: Once on the host, the attacker queries the cloud instance metadata service (IMDS at ``169.254.169.254``). They extract temporary IAM session tokens associated with the runner's cloud instance role. If the runner instance has permissions to manage S3, push to ECR, or touch Kubernetes clusters, your entire cloud organization is compromised. 3. Persistent Pipeline Backdoors: Attackers can silently install rootkits, modify adjacent container volumes, or poison production build artifacts before they are deployed.
Hardening production CI/CD runner platforms requires eliminating privileged daemon sockets: • Adopt Rootless Podman & Quadlets: Deploy sovereign CI/CD runners (like Forgejo Act Runner) using rootless Podman supervised by systemd Quadlets. Containers run entirely inside user namespaces without root privileges on the underlying host. • Use Daemonless Image Builders: Replace Docker build commands with daemonless build tools like ``kaniko``, ``buildah``, or ``podman build``. These tools assemble OCI images completely in user space without requiring access to a host daemon socket. • Enforce IMDSv2 and Hop Limits: Configure your cloud provider to mandate IMDSv2 (requiring token-based HTTP PUT handshakes) and enforce an HTTP hop limit of 1 (``http-put-response-hop-limit=1``). This prevents containers running inside the VM from reaching the metadata endpoint entirely. • Ephemeral Disposable VMs: For untrusted public pipelines, run jobs inside single-use, ephemeral KVM virtual machines that are destroyed immediately upon job completion.
Stop insecure pipeline breakouts and protect your production cloud credentials.
Deploy a secure, air-gapped developer platform with our 1-to-2 week Sovereign Git Forge & CI/CD Runner Platform Sprint on Contra: https://contra.com/s/7vW66W2v-sovereign-git-forge-and-cicd-runner-platform-deployment
#Security #DevOps #Docker #CyberSecurity #Cloud #Infrastructure #SRE
securitydevopsDockerCybersecuritycloudinfrastructuresre
Post image
Back to feed
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started