11.3.1.3 Pipeline Socket Exposure
A focused guide to Pipeline Socket Exposure, connecting core concepts with practical Docker and container operations.
Pipeline socket exposure refers to a CI/CD pipeline mounting the Docker socket into a build container — often to allow that build to itself build and push Docker images — a common, seemingly practical pattern that carries the same severe security implications as any other Docker socket mount.
Why Pipelines Commonly Encounter This Pattern
A CI job that needs to build a Docker image as part of its pipeline often does so by running Docker commands from within a containerized build environment, requiring access to a Docker daemon to actually perform that build.
steps:
- name: Build image
image: docker:24
volumes:
- /var/run/docker.sock:/var/run/docker.sock
script: docker build -t myapp:1.0 .
This configuration, while functionally straightforward, exposes the same severe Docker socket risk as any other socket mount, within the specific context of a CI pipeline's build step.
Why This Risk Is Easy to Overlook in a CI Context
A CI pipeline configuration is often treated as routine infrastructure rather than something requiring the same security scrutiny as application code, making this particular exposure easy to overlook despite its severity.
grep -r "docker.sock" .gitlab-ci.yml .github/workflows/
Specifically searching CI configuration for this pattern helps surface instances that might otherwise go unnoticed.
Why a Compromised Build Step Has Severe Implications Here
A CI pipeline often runs code from a pull request or branch not yet fully trusted — if that build step has Docker socket access, a malicious or compromised dependency pulled in during the build could leverage that access to compromise the broader CI infrastructure.
script: npm install && npm run build
If a malicious package introduced through this install step can also reach the mounted socket, the implications extend well beyond just this one build.
Using a Safer Alternative for Building Images in CI
Tools like Kaniko or BuildKit's rootless mode can build container images without requiring access to a full Docker daemon socket, substantially reducing this specific exposure.
/kaniko/executor --context=. --destination=myapp:1.0
Why Pipeline Socket Exposure Matters
Recognizing that this common CI pattern carries the same severe risk as any other Docker socket mount, particularly given that CI pipelines often execute less-trusted code, makes seeking out a safer image-building alternative an important security consideration for CI/CD infrastructure.