Container-Security on K-Life Hack | Systems Architecture & DevOps

Architecture Comparison and Implementation Conflict Analysis of DinD and DooD in GitLab CI

Wed, 03 Jun 2026 23:55:47 +0900

title: Docker Build Strategies in GitLab CI/CD: Technical Comparison and Selection Criteria for DinD and DooD meta_description: Explains the architecture, security, and implementation constraints of DinD (Docker-in-Docker) and DooD (Docker-out-of-Docker) for building Docker containers in GitLab CI/CD pipelines from a technical perspective.

In GitLab CI/CD pipelines, the requirement to execute docker build or docker push within a containerized runner is common. Two main architectural patterns exist for achieving this “container-in-container” approach: Docker-in-Docker (DinD) and Docker-out-of-Docker (DooD). This article analyzes their respective technical structures, security implications, and fatal conflict issues that occur during implementation.

Reconfirming Docker’s Client-Server Model

To understand the differences between DinD and DooD, it is necessary to recognize that Docker is a client-server architecture. Docker commands are separated into the following two components:

Docker CLI (Client): The interface that receives user commands and sends them to the server.
dockerd (Daemon/Server): The background process that actually executes image builds, volume management, and container orchestration.

When running Docker inside a container, “where the Docker Daemon exists” is the core of the architecture.

Structure and Characteristics of Docker-in-Docker (DinD)

DinD is a method of running a completely independent Docker Daemon inside a container.

Mechanism

A dedicated “service” container runs the DinD image and initializes its own isolated Docker Daemon. The build container’s CLI typically connects to this internal daemon via a network socket such as tcp://docker:2375.

Necessity of Privileged Mode

To operate DinD, privileged = true must be enabled in the GitLab Runner configuration. This is because the internal daemon requires high-level access to kernel features, such as creating cgroups and managing network namespaces.

Pros and Cons

Pros: Suitable for multi-tenant environments as it is completely isolated from the host environment and other build jobs.
Cons: High overhead and a tendency for performance degradation because a new daemon is started for each job. It also carries security risks associated with the use of privileged mode.

Structure and Characteristics of Docker-out-of-Docker (DooD)

DooD is a method where the CLI inside the container communicates directly with the host machine’s Docker Daemon.

Mechanism

Achieved by mounting the host’s Docker socket file (/var/run/docker.sock) into the container.

Configuration Example

[runners.docker]
 volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"]

Also, specify environment variables in .gitlab-ci.yml.

variables:
 DOCKER_HOST: unix:///var/run/docker.sock

Pros and Cons

Pros: Faster and simpler to implement than DinD because no additional daemon startup is required.
Cons: Zero isolation. Since the container shares the host’s daemon, it can manipulate all images and containers on the host. Mounting docker.sock is essentially synonymous with granting host root privileges to the container, making the risk of container escape extremely high.

Comparison of Security Hierarchies

The security strength of each method is as follows (higher security toward the bottom).

DooD: Lowest. Allows host-level root access via socket mounting.
DinD: Moderate. Isolated from the host, but requires privileged mode, which could become an attack vector to the host if the container is compromised.
BuildKit (rootless): Highest. A modern standard approach that operates daemonless without requiring privileged access or socket mounting.

Technical Constraint: Mutual Exclusivity of DinD and DooD

As an important engineering note, DinD and DooD cannot be used together within a single GitLab Runner configuration. Attempting to mix them will cause jobs to fail due to the following logical breakdown:

If a volume mount for /var/run/docker.sock is described in the GitLab Runner’s config.toml, this mount is applied to all containers (including service containers) generated by that runner.
When the DinD service container starts, it attempts to initialize a Docker Daemon inside itself.
The DinD daemon attempts to create its own socket at /var/run/docker.sock, but a socket mounted from the host already exists at that location.
The system returns a “device or resource busy” error, and the DinD daemon fails to start.

Therefore, when using DinD, the /var/run/docker.sock mount must be explicitly excluded from config.toml. The design principle is to have a runner dedicated to a single method.

Operational Notes

Criteria for selecting an implementation strategy are as follows:

Multi-tenant / High Security Requirements: Select DinD to ensure isolation between jobs.
Single User / Speed Priority: Select DooD to minimize overhead.
Modern CI/CD Environments: Consider adopting 🛠️ BuildKit (rootless). BuildKit supports multi-architecture builds and native secret management without requiring privileged mode, achieving both performance and security.

Implementation of Container Image Security Scan Automation in CI/CD Pipelines

Sat, 30 May 2026 10:33:07 +0900

Construction and Optimization Strategies for Security Automation in Container Delivery

In modern software delivery, ensuring container image security should be a priority equivalent to functional implementation. To identify risks lurking within the vast libraries and dependencies contained in images, an automated scanning process integrated into the CI/CD pipeline is essential, rather than manual inspection. This article explains technical approaches for naturally establishing security as part of the development workflow.

1. Strategic Background of Automated Scanning

The primary burden facing development teams is not only the functional integrity of the code but also the elimination of potential risk factors included in the deployment. Manual image inspection is prone to human error and tends to be omitted within tight release schedules. Therefore, automation is not merely an option but a prerequisite for achieving secure delivery.

Building an immediate feedback loop: Embed scanners within the build process to immediately fail the build or notify alerts if vulnerabilities are detected. This prevents vulnerable code from propagating to production environments.
Granular policy application: Beyond simply introducing tools, formulate blocking policies based on vulnerability severity (Critical, High, Medium, etc.).
Promoting standardization: By applying unified security benchmarks across the entire team, eliminate variations in judgment based on individual subjectivity and minimize security gaps.

2. Technical Optimization in CI/CD Integration

Pipeline execution speed directly impacts developer productivity. Strategies are needed to ensure security scanning does not excessively increase build times. Optimization at the infrastructure level is required to achieve efficient scanning.

Performance Improvement Methods

Leveraging layer caching: Introduce caching mechanisms that target only changed layers for scanning to reduce redundant processing.
Image weight reduction: Adopt multi-stage builds and distroless images to eliminate unnecessary packages, narrowing the scope of the scan and shortening deployment time.

# Example of reducing attack surface via multi-stage builds
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY . .
RUN go build -o main .

# Minimal binary placement in execution environment
FROM gcr.io/distroless/static-debian12
COPY --from=builder /app/main /main
CMD ["/main"]

Vulnerability Database Management

The effectiveness of a scanner depends on the freshness of the database it references. Update policies must be strictly managed to ensure the latest vulnerability definitions are reflected in real-time, reducing the risk of false negatives.

3. Layering Automated Security Inspection Frameworks

To increase system reliability and accelerate root cause analysis during failures, the inspection process is structured. It is important to select tools appropriate for each phase.

Phase	Main Inspection Items	Examples of Automation Tools	Implementation Timing
Build Phase	Vulnerabilities in source code	SAST tools	Immediately after commit
Image Creation	OS package/dependency vulnerabilities	Trivy, Clair	Upon build completion
Deployment Verification	Config file permissions/compliance	OPA, Kyverno	Immediately before deployment

4. Advanced Security Controls and Scaling

As the scale of the organization grows, manual verification reaches its limits. Introduce the concept of Policy as Code (PaC) and aim for a scalable design.

Image signing and integrity verification: Use tools such as Cosign or Notary to restrict execution in production environments to only signed and verified images. This mitigates the risk of supply chain attacks.
Admission controller integration: In Kubernetes environments, use Admission Controllers to enforce policies that reject the deployment of containers that do not meet security standards at the cluster level.

# Example of running a scan in a CI pipeline using Trivy
trivy image --severity CRITICAL,HIGH --exit-code 1 my-repository/my-app:latest

5. Developer Experience and Alert Fatigue Management

Excessive warning messages cause “alert fatigue,” leading to the erosion of security protocols. Adjustments are necessary to ensure operational sustainability.

Priority-based notifications: Limit low-priority warnings to log entries, and set “Fail” thresholds that stop the pipeline only for vulnerabilities directly linked to actual business risks.
Thorough secret management: To prevent sensitive information from being hardcoded in environment variables or configuration files during the build process, integrate with secret management tools within virtualized environments.

Operational Notes

Rethinking cache strategies: 💡 If increased build time is an issue, consider moving to an incremental scanning method triggered only when image layers or dependencies change, rather than performing a full scan daily.
Ensuring visibility: 🛠️ By building a dashboard to track vulnerability trends in running images, it becomes possible to make data-driven decisions on the direction of future security improvements.
Log integration: ⚠️ It is recommended to integrate logging environments so that when a deployment error occurs, it can be quickly determined whether it is due to a functional defect or a security policy violation.