導入
コンテナの軽量化といえばAlpine Linuxが有名ですが、セキュリティを最優先するプロダクション環境において、今注目すべきは「Distroless」です。Distrolessは、パッケージマネージャやシェルすら含まない極限まで削ぎ落とされたイメージであり、コンテナへの侵入を試みる攻撃者に対して「足がかり」を一切与えません。本番環境の攻撃サーフェス（攻撃可能な領域）を最小化し、堅牢なシステムを構築するために、なぜDistrolessが選ばれるのかを解説します。
基礎知識
Distrolessとは、Googleが開発・公開している「アプリケーションとその実行に必要な依存関係のみ」を含むコンテナイメージです。一般的なOSイメージ（UbuntuやAlpineなど）には、/bin/shやapt、curlといったツールが含まれていますが、これらは攻撃者が侵入後に環境を探索したり、追加のツールをダウンロードしたりするために悪用されます。Distrolessにはこれらが一切含まれていないため、万が一アプリケーションに脆弱性があっても、攻撃者はシェルを起動してコマンドを実行することができません。
実装/解決策
Distrolessを採用する際の基本戦略は「マルチステージビルド」です。ビルド環境（コンパイラやライブラリ）と実行環境を分離し、最終的なイメージには実行に必要なバイナリのみをコピーします。これにより、イメージサイズを劇的に小さくしつつ、セキュリティを最大化できます。
サンプルプログラム
以下は、Go言語のアプリケーションをDistrolessでビルドする際の典型的なDockerfile例です。
ビルド用ステージ
FROM golang:1.21-bullseye AS builder
WORKDIR /app
COPY . .
静的リンクでバイナリを作成（Distrolessで動かすために重要）
RUN CGO_ENABLED=0 GOOS=linux go build -o /my-app main.go
実行用ステージ（Distrolessを使用）
FROM gcr.io/distroless/static-debian11
ビルド済みバイナリのみをコピー
COPY –from=builder /my-app /my-app
非rootユーザーで実行（セキュリティのベストプラクティス）
USER nonroot:nonroot
アプリケーションの起動
ENTRYPOINT [“/my-app”]
応用・注意点
現場でDistrolessを運用する際に必ず直面するのが「デバッグの困難さ」です。シェルが含まれていないため、コンテナ内で「ls」や「cat」を実行することはできません。
回避策1: エフェメラルコンテナの活用
Kubernetes環境であれば、kubectl debugコマンドを使用して、実行中のコンテナに一時的なデバッグ用コンテナをアタッチし、そこからプロセスを確認する方法が推奨されます。
回避策2: ログとトレースの徹底
Distroless環境ではコンテナ内に入って調査することは諦め、アプリケーションのログ出力（stdout/stderr）や、OpenTelemetryなどの分散トレースを充実させることが運用上の正攻法です。
注意点
Alpine Linuxと比較すると、Distrolessはlibcの互換性問題などで稀に動作しないライブラリが存在します。特にCGOを使用するライブラリを含める場合は、事前に動作検証を十分に行うようにしてください。セキュリティと運用工数のバランスを見極めるのが、DevOpsエンジニアの腕の見せ所です。
コメント