✦ For everyone, free.

Practical knowledge for real and everyday life

Home

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.