先週、本番環境へのデプロイパイプラインが突然停止しました。原因は、CI/CDに統合していたTrivyによる脆弱性スキャンが「Critical」レベルのCVE（共通脆弱性識別子）を20件以上検出したためです。使用していたベースイメージは一般的な node:18-bullseye でしたが、OSレイヤーに含まれる未使用のライブラリ（OpenSSLの古いバージョンやSystemd関連）がセキュリティホールとなっていました。開発速度を維持しつつ、Dockerセキュリティ要件を満たすためには、単なるパッチ当てではなく、アーキテクチャレベルでの「ダイエット」が必要でした。
現状分析：なぜ標準イメージは危険なのか
当時の私たちの環境は、AWS EKS上で動作するマイクロサービス群で、Node.jsとGoが混在していました。標準のDebianベースのイメージは便利ですが、本番運用には「余計なもの」が多すぎます。curl、wget、apt、そして何より /bin/bash です。これらは攻撃者がコンテナ内に侵入した際、横展開（ラテラルムーブメント）するための強力な武器となります。
DevSecOps の観点からは、「攻撃対象領域（Attack Surface）の最小化」が鉄則です。800MBを超えるイメージサイズは、スケーリング時のプル時間を遅延させるだけでなく、管理すべき脆弱性の数を指数関数的に増やしてしまいます。
CRITICAL: CVE-2023-xxxx (openssl) - Fixed in 1.1.1t-r0これが数百行出力され、開発チームは対応に追われていました。
私たちは当初、イメージサイズを小さくするために Alpine Linux への移行を試みました。
Alpine Linuxでの失敗と教訓
「軽量化といえばAlpine」というのは一般的な認識ですが、私たちのケースでは致命的な問題が発生しました。Alpineは標準の glibc ではなく musl libc を採用しています。これにより、一部のネイティブモジュール（特に画像処理系のライブラリやgRPC関連）がセグメンテーション違反を起こし、本番相当の負荷テストでクラッシュしました。
また、Alpineのパッケージマネージャである apk が存在すること自体、セキュリティ的にはまだ「攻撃の余地」を残していることになります。そこで辿り着いたのが、Googleが提唱する Distrolessイメージ でした。
解決策：Distrolessとマルチステージビルド
Distrolessイメージには、パッケージマネージャもシェルもありません。アプリケーションとその依存関係を実行するためだけの最小限のランタイムしか含まれていないのです。
以下は、Node.jsアプリケーションを例にした、コンテナ最適化とセキュリティ強化を同時に実現するマルチステージビルドの完成形です。
# ビルドステージ（Debianベースでビルドツールをフル活用）
FROM node:18-bullseye-slim AS builder
WORKDIR /app
# キャッシュ効率化のために依存関係定義のみを先にコピー
COPY package*.json ./
# 開発依存も含めてインストール（ビルドに必要）
# --frozen-lockfile でlockファイルとの整合性を保証
RUN npm ci
COPY . .
# TypeScriptのビルドや不要ファイルの削除
RUN npm run build \
&& npm prune --production
# 実行ステージ（Distrolessへ移行）
# gcr.io/distroless/nodejs:18 を使用
FROM gcr.io/distroless/nodejs18-debian11
WORKDIR /app
# ビルドステージから必要なアーティファクトのみをコピー
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/package.json ./
# セキュリティ強化: rootユーザーを使わない（Distrolessはnonrootユーザーを内蔵）
USER nonroot:nonroot
# シェルがないため、CMDは配列形式で記述必須
CMD ["dist/main.js"]この構成の肝は、ビルド環境と実行環境の完全な分離です。builder ステージではコンパイラやnpmコマンドが必要ですが、最終的なイメージにはこれらは一切不要です。Distrolessを採用することで、OSレベルの脆弱性の99%を物理的に排除できます。
効果検証：サイズと脆弱性数の劇的変化
導入後、実際にどれだけの効果があったのかを定量的に評価しました。以下は、移行前（Debian Slim）と移行後（Distroless）の比較データです。
| 指標 | Debian Slim (Node:18) | Distroless (Node:18) | 改善率 |
|---|---|---|---|
| イメージサイズ | 180 MB | 65 MB | 64% 削減 |
| High/Critical脆弱性 | 24件 | 0件 | 100% 削減 |
| シェルアクセスの可否 | 可能 (危険) | 不可能 | 堅牢化 |
イメージ軽量化の結果、KubernetesのPod起動時間が平均で1.2秒短縮されました。また、脆弱性スキャンがグリーン（問題なし）になったことで、DevSecOpsパイプラインがブロックされることなくスムーズに回るようになりました。
特筆すべきは、シェルが存在しないことによるセキュリティ効果です。万が一アプリケーションにRCE（リモートコード実行）の脆弱性があったとしても、攻撃者はシェルを起動できず、curl でマルウェアをダウンロードすることもできないため、攻撃の連鎖を断ち切ることができます。
注意点とデバッグ手法
Distrolessは本番環境には最適ですが、運用の難易度は上がります。最も大きなハードルは「コンテナに入れない」ことです。
docker exec -it my-container bash は動作しません。シェルが存在しないためです。
本番環境でトラブルシューティングを行う場合、以下の2つのアプローチを推奨します：
- debugタグの使用: 開発環境やステージング環境では、シェル（BusyBox）が含まれている
:debugタグのイメージ（例:gcr.io/distroless/nodejs:18-debug）を使用する。 - Kubernetes Ephemeral Containers: K8s 1.23以降であれば、
kubectl debugコマンドを使用して、既存のPodにデバッグ用のコンテナを一時的にアタッチできます。これにより、稼働中のDistrolessコンテナに対して外部からツールを持ち込んで調査が可能になります。
結論
Dockerイメージの最適化は、単なるディスク容量の節約ではありません。それは、システム全体のセキュリティポスチャを向上させるための重要なエンジニアリングです。安易にAlpineを選ぶのではなく、アプリケーションの互換性とセキュリティ要件を天秤にかけ、Distrolessという選択肢を検討してください。OSパッケージの管理から解放されることで、私たちはアプリケーションコードの質を高めることに集中できるようになります。
Post a Comment