Container-Security on K-Life Hack | システムアーキテクチャ & DevOps

GitLab CIにおけるDinDとDooDのアーキテクチャ比較と実装上の競合分析

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

title: GitLab CI/CDにおけるDockerビルド戦略：DinDとDooDの技術的比較と選定基準 meta_description: GitLab CI/CDパイプラインでDockerコンテナをビルドするためのDinD（Docker-in-Docker）とDooD（Docker-out-of-Docker）のアーキテクチャ、セキュリティ、および実装上の制約を技術的視点から解説します。

GitLab CI/CDパイプラインにおいて、コンテナ化されたランナー内でdocker buildやdocker pushを実行する要件は一般的です。この「コンテナ内コンテナ」を実現する手法として、主にDocker-in-Docker (DinD) と Docker-out-of-Docker (DooD) の2つのアーキテクチャパターンが存在します。本稿では、それぞれの技術的構造、セキュリティ上のインプリケーション、および実装時に発生する致命的な競合問題について分析します。

Dockerのクライアント・サーバーモデルの再確認

DinDとDooDの差異を理解するためには、Dockerがクライアント・サーバーアーキテクチャであることを認識する必要があります。Dockerコマンドは以下の2つのコンポーネントに分離されています。

Docker CLI (Client): ユーザーのコマンドを受け取り、サーバーに送信するインターフェース。
dockerd (Daemon/Server): イメージのビルド、ボリューム管理、コンテナのオーケストレーションを実際に実行するバックグラウンドプロセス。

コンテナ内でDockerを実行する場合、この「Docker Daemonがどこに存在するか」がアーキテクチャの核心となります。

Docker-in-Docker (DinD) の構造と特性

DinDは、コンテナの内部で完全に独立したDocker Daemonを実行する手法です。

メカニズム

専用の「サービス」コンテナがDinDイメージを実行し、独自の隔離されたDocker Daemonを初期化します。ビルドコンテナのCLIは、通常 tcp://docker:2375 などのネットワークソケットを介して、この内部デーモンに接続します。

特権モード (Privileged Mode) の必要性

DinDを動作させるには、GitLab Runnerの設定で privileged = true を有効にする必要があります。これは、内部デーモンがcgroupsの作成やネットワークネームスペースの管理など、カーネル機能への高度なアクセス権限を必要とするためです。

メリットとデメリット

メリット: ホスト環境や他のビルドジョブから完全に隔離されるため、マルチテナント環境に適しています。
デメリット: ジョブごとに新しいデーモンを起動するためオーバーヘッドが大きく、パフォーマンスが低下する傾向があります。また、特権モードの使用に伴うセキュリティリスクを伴います。

Docker-out-of-Docker (DooD) の構造と特性

DooDは、コンテナ内のCLIがホストマシンのDocker Daemonと直接通信する手法です。

メカニズム

ホストのDockerソケットファイル（/var/run/docker.sock）をコンテナ内にマウントすることで実現します。

設定例

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

また、.gitlab-ci.yml で環境変数を指定します。

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

メリットとデメリット

メリット: 追加のデーモン起動が不要なため、DinDよりも高速かつシンプルに実装可能です。
デメリット: 隔離性が皆無です。コンテナがホストのデーモンを共有するため、ホスト上の全イメージやコンテナを操作可能になります。docker.sock のマウントは、実質的にコンテナへホストのroot権限を付与することと同義であり、コンテナエスケープのリスクが極めて高い構成です。

セキュリティ階層の比較

手法ごとのセキュリティ強度は以下の通りです（下に行くほど高セキュリティ）。

DooD: 最も低い。ソケットマウントによりホストレベルのrootアクセスを許可する。
DinD: 中程度。ホストからは隔離されるが、privileged モードが必要であり、コンテナが侵害された場合にホストへの攻撃ベクトルとなる可能性がある。
BuildKit (rootless): 最も高い。特権アクセスやソケットマウントを必要とせず、デーモンレスで動作する現代的な標準アプローチ。

技術的制約：DinDとDooDの共存不可問題

エンジニアリング上の重要な注意点として、単一のGitLab Runner構成においてDinDとDooDを併用することはできません。これらを混在させようとすると、以下の論理的破綻によりジョブが失敗します。

GitLab Runnerの config.toml に /var/run/docker.sock のボリュームマウントが記述されている場合、そのランナーが生成するすべてのコンテナ（サービスコンテナを含む）にこのマウントが適用されます。
DinDサービスコンテナが起動する際、自身の内部でDocker Daemonを初期化しようとします。
DinDデーモンは /var/run/docker.sock に自身のソケットを作成しようとしますが、その場所には既にホストからマウントされたソケットが存在します。
システムは “device or resource busy” エラーを返し、DinDデーモンの起動に失敗します。

このため、DinDを使用する場合は、config.toml から /var/run/docker.sock のマウントを明示的に除外する必要があります。ランナーは一つの手法に専念させるのが設計上の原則です。

Operational Notes

実装戦略を選択する際の基準は以下の通りです。

マルチテナント / 高セキュリティ要件: DinDを選択し、ジョブ間の隔離を確保します。
単一ユーザー / 速度優先: DooDを選択し、オーバーヘッドを最小化します。
モダンなCI/CD環境: 🛠️ BuildKit (rootless) の採用を検討してください。BuildKitは、特権モードを必要とせず、マルチアーキテクチャビルドやネイティブなシークレット管理をサポートしており、パフォーマンスとセキュリティの両立が可能です。

CI/CDパイプラインにおけるコンテナイメージ・セキュリティスキャン自動化の実装

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

コンテナデリバリーにおけるセキュリティオートメーションの構築と最適化戦略

現代のソフトウェアデリバリーにおいて、コンテナイメージのセキュリティ確保は、機能実装と同等の優先順位を持つべき課題です。イメージ内に含まれる膨大なライブラリや依存関係に潜むリスクを特定するためには、手動の検査ではなく、CI/CDパイプラインに組み込まれた自動化スキャンプロセスが不可欠となります。本稿では、セキュリティを開発ワークフローの一部として自然に定着させるための技術的アプローチについて解説します。

1. 自動化スキャンの戦略的背景

開発チームが直面する主な負担は、コードの機能的完全性だけでなく、デプロイメントに含まれる潜在的なリスク要因の排除です。手動によるイメージ検査はヒューマンエラーを招きやすく、タイトなリリーススケジュールの中では省略される傾向にあります。したがって、自動化は単なるオプションではなく、セキュアなデリバリーを実現するための前提条件となります。

即時フィードバックループの構築: ビルドプロセス内にスキャナーを埋め込み、脆弱性が検出された場合に即座にビルドを失敗させる、あるいはアラートを通知する仕組みを構築します。これにより、脆弱なコードが本番環境に伝播するのを未然に防ぎます。
粒度の高いポリシー適用: 単にツールを導入するだけでなく、脆弱性の深刻度（Critical, High, Medium等）に基づいたブロッキングポリシーを策定します。
標準化の推進: チーム全体で統一されたセキュリティベンチマークを適用することで、個人の主観による判断のばらつきを排除し、セキュリティギャップを最小化します。

2. CI/CD統合における技術的最適化

パイプラインの実行速度は開発者の生産性に直結します。セキュリティスキャンがビルド時間を過度に増大させないための戦略が必要です。効率的なスキャンを実現するためには、インフラレベルでの最適化が求められます。

パフォーマンスの向上手法

レイヤーキャッシュの活用: 変更があったレイヤーのみをスキャン対象とするキャッシュメカニズムを導入し、重複した処理を削減します。
イメージの軽量化: マルチステージビルドやdistrolessイメージを採用し、不要なパッケージを排除することで、スキャン対象の範囲を絞り込み、デプロイ時間を短縮します。

# マルチステージビルドによるアタックサーフェスの削減例
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY . .
RUN go build -o main .

# 実行環境には最小限のバイナリのみを配置
FROM gcr.io/distroless/static-debian12
COPY --from=builder /app/main /main
CMD ["/main"]

脆弱性データベースの管理

スキャナーの有効性は、参照するデータベースの鮮度に依存します。最新の脆弱性定義がリアルタイムで反映されるよう、更新ポリシーを厳格に管理し、偽陰性（False Negative）のリスクを低減させる必要があります。

3. 自動セキュリティ検査フレームワークの階層化

システムの信頼性を高め、障害発生時の原因究明を迅速化するために、検査工程を構造化します。各フェーズに適したツールを選択することが重要です。

フェーズ	主な検査項目	自動化ツールの例	実装タイミング
ビルド段階	ソースコード内の脆弱性	SASTツール	コミット直後
イメージ作成	OSパッケージ・依存関係の脆弱性	Trivy, Clair	ビルド完了時
デプロイ検証	設定ファイルの権限・コンプライアンス	OPA, Kyverno	デプロイ直前

4. 高度なセキュリティ制御とスケーリング

組織の規模が拡大するにつれ、手動による検証は限界を迎えます。ポリシー・アズ・コード（PaC）の概念を導入し、スケーラブルな設計を目指します。

イメージ署名と整合性検証: CosignやNotaryなどのツールを使用し、署名済みの検証済みイメージのみが本番環境で実行されるように制限します。これにより、サプライチェーン攻撃のリスクを軽減します。
アドミッションコントローラーの統合: Kubernetes環境では、Admission Controllerを利用して、セキュリティ基準を満たさないコンテナのデプロイをクラスターレベルで拒否するポリシーを強制します。

# Trivyを使用したCIパイプラインでのスキャン実行例
trivy image --severity CRITICAL,HIGH --exit-code 1 my-repository/my-app:latest

5. 開発者エクスペリエンスとアラート疲れの管理

過剰な警告メッセージは「アラート疲れ」を引き起こし、セキュリティプロトコルに対する形骸化を招きます。運用の持続性を確保するための調整が必要です。

優先順位に基づいた通知: 重要度の低い警告はログに記録するに留め、パイプラインを停止させる「Fail」の閾値は、実際のビジネスリスクに直結する脆弱性に絞って設定します。
シークレット管理の徹底: ビルドプロセスにおいて、環境変数や設定ファイルに機密情報がハードコードされないよう、シークレット管理ツールとの統合を仮想化された環境で行います。

Operational Notes

キャッシュ戦略の再考: 💡 ビルド時間の増大が課題となる場合、毎日フルスキャンを行うのではなく、イメージレイヤーや依存関係に変更があった場合のみトリガーされる増分スキャン方式への移行を検討してください。
可視性の確保: 🛠️ 実行中のイメージの脆弱性推移を追跡するダッシュボードを構築することで、将来的なセキュリティ改善の方向性をデータに基づいて判断することが可能になります。
ログの統合: ⚠️ デプロイエラーが発生した際、それが機能的な不具合によるものか、セキュリティポリシー違反によるものかを迅速に判別できるよう、ログ環境を統合しておくことが推奨されます。