unprivileged かつ distroless なイメージ について理解しようぜ

コンテナ技術は現代のアプリケーション開発・運用に欠かせないものとなりましたが、コンテナを運用する上で「セキュリティ」と「イメージサイズ」は常に大きな課題として立ちはだかります。

あなたのコンテナイメージは本当に安全で、そして最小限に保たれていますか？

多くの開発者は、手軽さからコンテナをroot（管理者）権限で実行し、また開発やデバッグに不要なOSパッケージをそのまま含めてしまいがちです。

これが、セキュリティリスクの増大と、イメージサイズの肥大化を招く原因となります。

この記事では、この課題を解決するための Unprivileged（非特権ユーザー実行）とDistroless（ディストロレス）イメージについて、その概念から実践的な使い方、そして運用上の注意点までを解説します。

そもそも「Unprivileged」と「Distroless」とは何か？

1. Unprivileged (非特権ユーザー実行) とは？

Unprivileged実行とは、「最小特権の原則」をコンテナで実践することです。

• 定義
  コンテナ内のメインプロセスをrootユーザー（UID 0）ではなく、一般ユーザー（非特権ユーザー）として実行すること。
• メリット
  コンテナが何らかの理由で侵害されたり、エスケープ（コンテナの外側にあるホストOSへの侵入）が試みられたりした場合でも、プロセスが持つ権限が最小限に抑えられます。
  これにより、ホストシステムへの影響範囲を劇的に制限できます。
• 実現方法
  Dockerfile内でUSER命令を使用して、コンテナの実行ユーザーを切り替えます。

2. Distroless (ディストロレス) イメージとは？

Distrolessイメージとは、セキュリティとサイズを極限まで追求したベースイメージです。

• 定義
  OSディストリビューション（Linux）の要素、具体的にはbash、apt、lsといった一般的なシェルやパッケージ管理ツールを意図的に含めない、アプリケーション実行に必要な最小限のランタイムとライブラリのみで構成されたコンテナイメージです。
• 「通常のイメージ」との違い
  通常のイメージ（例: ubuntu:latest）には多くの汎用ツールが含まれていますが、Distrolessイメージにはそれらが一切含まれていません。デバッグツールさえないため、その名（Distro-less = ディストリビューションがない）が示す通り、極めて軽量です。

Unprivileged & Distroless を組み合わせるメリット

この二つのアプローチを組み合わせることで、コンテナの運用は次のレベルに引き上げられます。

1. 圧倒的なセキュリティ向上

• 攻撃対象領域の削減
  Distroless化により、イメージに含まれるバイナリやライブラリの数が最小限になります。
  その結果、既知の脆弱性（CVE）を持つ可能性のあるパッケージが激減し、攻撃対象となる領域を大幅に縮小します。
• 権限昇格リスクの低減
  Unprivileged実行により、仮にコンテナに侵入されても、攻撃者がホストシステムでroot権限を得るのが極めて困難になります。

2. イメージサイズの劇的な削減

• 不要なOSレイヤーやツールがないため、イメージサイズは通常のベースイメージに比べて数百MB単位で削減されることがあるらしい
• これにより、レジストリへのプッシュ/プル時間が短縮され、デプロイ時間の高速化、そしてストレージコストの削減につながります。

3. ビルド時間の短縮と効率化

ベースイメージが小さくなることで、CI/CDパイプラインでのダウンロード時間が短縮され、コンテナのビルドプロセス全体が効率化されます。

Unprivileged & Distroless なコンテナの使い方

Unprivileged & Distrolessを実現する最も一般的な方法は、マルチステージビルドを利用することです。

1. Distroless イメージの基本構造

1. Build Stage
   開発に必要なコンパイラ、パッケージマネージャなどを含む通常のイメージ（例: golang:latest, node:latest）を使い、アプリケーションのビルドや依存関係のインストールを行います。
2. Final Stage
   Distrolessイメージをベースとし、Build Stageで生成された最終的なバイナリや必要なランタイムファイルだけをコピーします。

2. Unprivileged実行の設定

Distrolessイメージの多く（例: gcr.io/distroless/...）は、セキュリティのため、デフォルトで非rootユーザー（例: nonroot）が設定されています。

もしご自身でベースイメージから構築する場合、Dockerfileに以下のコマンドを追加してユーザーを切り替えます。

# ユーザーを作成し、パーミッションを設定
RUN adduser --disabled-password --gecos "" appuser

# 実行ユーザーを一般ユーザーに切り替える
USER appuser

運用上の注意点：非特権ユーザーとポート番号の壁

UnprivilegedコンテナをECS（または任意のLinuxホスト）で運用する際、セキュリティの恩恵と引き換えに、ある実用上の課題に直面します。

1. ポート1024未満のバインドはroot権限が必要

Linux OSのセキュリティ原則により、Webサーバーなどで一般的に使われるポート番号1024未満（ウェルノウンポート、例: HTTPの80、HTTPSの443）にバインドするには、root権限（特権）が必要です。

あなたがECSでUnprivilegedかつDistrolessなNginxイメージを使った際、Nginxがデフォルトで80番ポートを使おうとすると、権限がないため「Permission Denied」といったエラーが発生し、コンテナの起動に失敗してしまいます。

2. ECS/Fargate環境での具体的な解決策

この問題を解決しつつ、Unprivilegedのセキュリティメリットを維持するには、以下の方法が最も推奨されます。

1. アプリケーション側のポート変更:Webサーバー（Nginxなど）の設定ファイルを変更し、1024番以上のポート（例: 8080、8081）で待ち受けるように設定を変更します。
2. ロードバランサー (ALB) でのポートマッピング:
   • ECS（Fargate）のタスク定義で、コンテナが使用するポートを8080などに設定します。
   • Application Load Balancer (ALB) を利用し、ALBは外部からのアクセスを80番（標準HTTP）で受けます。
   • ALBは、内部のECSタスクグループに対しては8080番でルーティングします。

これにより、コンテナ内部は非特権ユーザーで安全に運用され、外部ユーザーはポート番号を意識することなくWebサイトにアクセスできるようになります。

次世代コンテナの標準へ

UnprivilegedとDistrolessの組み合わせは、コンテナのセキュリティ基準とデプロイ効率を大きく引き上げる、次世代コンテナの標準パターンです。

• Distroless: 攻撃対象領域とイメージサイズを最小化。
• Unprivileged: 権限昇格リスクを最小化。

特にECSなどの本番環境で運用する際は、ポート1024未満の制限に注意を払い、ロードバランサーを活用して安全かつ効率的な構成を構築しましょう。

あなたのプロジェクトも、今日からこの強力なセキュリティパターンに移行してみませんか？