Dockerコンテナのセキュリティ強化｜特権コンテナ・rootless運用・イメージ脆弱性スキャンの実践ガイド

Dockerを本番環境で運用しているのに、コンテナのセキュリティ設定を「デフォルトのまま」にしていませんか？

Dockerはデフォルト状態でも一定の隔離を提供しますが、設定を誤ると攻撃者にとって格好の侵入口になります。特権コンテナ（–privileged）の誤用や、rootで実行されるコンテナが原因でホストサーバーまで侵害されたインシデントは、国内外で繰り返し報告されています。

この記事では、インフラエンジニア・社内SEが実践すべきDockerコンテナのセキュリティ強化手順を、攻撃者の視点を交えながら解説します。rootlessモードへの移行、ケーパビリティの最小化、Trivyを使った脆弱性スキャンまで、手を動かせるレベルで説明します。

Dockerコンテナのセキュリティリスクとは？

Dockerはプロセス隔離の仕組みとして「Linuxの名前空間（namespace）」と「cgroups（リソース制御）」を使っています。仮想マシンとは異なりカーネルを共有しているため、コンテナの設定が甘ければホスト側のカーネルや他コンテナに影響が及ぶリスクがあります。

攻撃者がコンテナに侵入した場合、次のような経路でエスカレーションを試みます。

・コンテナ逃脱（Container Escape）: 特権コンテナや危険なケーパビリティを悪用し、ホストのファイルシステムやプロセスに直接アクセスする
・ホスト共有ボリューム悪用: /var/run/docker.sockやホストの /etc をマウントされた場合、コンテナ内からホスト全体を制御可能になる
・イメージの脆弱性: 古いベースイメージや脆弱なパッケージを含むイメージからコンテナを起動すると、既知の脆弱性を突かれるリスクがある
・シークレット漏洩: Dockerfile内に直書きした認証情報や環境変数が、イメージ内に残存してレジストリから漏洩する

これらのリスクを「正しく知って正しく備える」ために、以降では具体的な強化手順を紹介します。

攻撃者はDockerのどこを狙うか

防御の前に「敵の目線」を持つことが重要です。攻撃者がDockerコンテナに侵入するシナリオの多くは、次のパターンに収束します。

1. 特権コンテナ（–privileged）からのホスト侵害

--privileged オプションをつけて起動したコンテナは、ホストのほぼすべてのデバイスにアクセスでき、ケーパビリティも全部付与されます。アプリケーションのデバッグや一時的な調査目的で使われることがありますが、本番環境でそのまま残ってしまうケースが後を絶ちません。

攻撃者がこのコンテナに侵入すると、ホストのディスクをマウントして /etc/shadow を読み取ったり、ホストのプロセス名前空間に侵入してシグナルを送ったりすることが可能です。

2. Docker APIソケットの露出

/var/run/docker.sock をコンテナ内にバインドマウントしている構成では、コンテナ内から新しいコンテナを起動したり、既存コンテナを操作したりできます。CI/CDパイプラインや監視ツールで意図的に使うケースもありますが、攻撃者にとってはホスト掌握の近道です。

3. rootユーザーで動くコンテナ

Dockerfileに USER 指定がない場合、コンテナはroot（UID 0）で動作します。コンテナ内でrootでも、ネームスペース分離のおかげでホスト側rootとは別物です。しかし、コンテナ逃脱の脆弱性（CVEベース）が発見されると、コンテナ内rootがホスト側rootに昇格できるリスクがあります。

具体的なセキュリティ強化手順

1. –privilegedは使わない。ケーパビリティを最小化する

原則として --privileged は使用禁止です。必要な権限だけをケーパビリティ単位で付与します。

# 悪い例: 全権限付与（本番では絶対NG）
# docker run --privileged myapp

# 良い例: 全ケーパビリティを落とし、必要なものだけ追加
docker run \
  --cap-drop ALL \
  --cap-add NET_BIND_SERVICE \
  myapp

主なケーパビリティと用途は以下の通りです。

2. rootlessモードで運用する

rootlessモードは、Dockerデーモン自体を一般ユーザー権限で動かす仕組みです。デーモンがrootである限りホスト全体のリスクになるため、本番環境では積極的に採用を検討してください。

# rootlessモードのセットアップ（Ubuntu/Debian系）
sudo apt-get install -y uidmap
dockerd-rootless-setuptool.sh install

# rootlessデーモンを有効化・起動
systemctl --user enable docker
systemctl --user start docker

# 動作確認
docker info | grep -i "rootless"

rootlessモードでは、コンテナが侵害されても攻撃者が掌握できるのは一般ユーザーの権限内にとどまります。ホストのrootには届きません。

3. コンテナのファイルシステムをread-onlyにする

多くのアプリケーションは、コンテナ内のファイルシステムへの書き込みを必要としません。--read-only フラグを使うと、コンテナ内のファイル改ざんを防げます。

# ファイルシステムをread-onlyに設定
# tmpfsでアプリが書き込みを必要とする一時領域は別途確保
docker run \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=64m \
  --tmpfs /var/run:rw,noexec,nosuid \
  myapp

攻撃者がコンテナ内でツールをダウンロードしたり、バックドアを設置しようとしても、ファイルシステムへの書き込みが拒否されます。

4. rootユーザーで動かさない（Dockerfileで USER を指定）

Dockerfileで非特権ユーザーを作成し、そのユーザーでアプリを実行します。

# Dockerfileの例
FROM ubuntu:22.04

# 依存パッケージのインストール（rootで実行）
RUN apt-get update && apt-get install -y myapp-deps

# 専用ユーザーを作成
RUN groupadd -r appuser && useradd -r -g appuser -s /sbin/nologin appuser

# 実行ユーザーを切り替え
USER appuser

CMD ["/usr/bin/myapp"]

USER 指定が最終行にない場合、後から追加されたレイヤーがrootに戻ってしまうことがあります。Dockerfile全体の最後に USER を配置するか、マルチステージビルドで明示的に管理してください。

5. Trivyでイメージの脆弱性をスキャンする

Trivyは、コンテナイメージやDockerfile内の既知の脆弱性（CVE）を高速にスキャンできるオープンソースツールです。CI/CDパイプラインに組み込むことで、脆弱性を含むイメージのデプロイを事前にブロックできます。

# Trivyのインストール（Ubuntu/Debian）
sudo apt-get install -y wget apt-transport-https gnupg
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
echo "deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main" \
  | sudo tee /etc/apt/sources.list.d/trivy.list
sudo apt-get update && sudo apt-get install -y trivy

# イメージをスキャン（CRITICALとHIGHのみ表示）
trivy image --severity CRITICAL,HIGH myapp:latest

# Dockerfileをスキャン（設定ミスの検出）
trivy config ./Dockerfile

スキャン結果にCRITICALが含まれる場合は、原則としてデプロイを止めてベースイメージを更新します。HIGHは影響範囲を確認したうえで対応優先度を判断します。

6. seccompプロファイルでシステムコールを制限する

Dockerはデフォルトでseccompプロファイルを適用しており、300以上あるシステムコールのうち危険なものをブロックしています。本番環境では、アプリケーションが使わないシステムコールをさらに絞り込んだカスタムプロファイルの適用が効果的です。

# デフォルトのseccompプロファイルを明示的に指定（確認用）
docker run --security-opt seccomp=/etc/docker/seccomp/default.json myapp

# カスタムプロファイルを使用する場合
docker run --security-opt seccomp=/path/to/custom-seccomp.json myapp

# seccompを無効化は絶対にしない
# docker run --security-opt seccomp=unconfined myapp  ← NG

seccompの詳細な設定方法については、姉妹サイトLinuxMaster.JPでLinuxのカーネルレベルのセキュリティ設定と合わせて解説しています。

中小企業でも今日からできること

フルセットの対応が難しい場合でも、優先順位をつけて段階的に対応できます。

・まず今日やること: 本番コンテナで --privileged が使われていないかを確認する（docker inspect コンテナ名 | grep -i privileged で確認）
・今週中にやること: Trivyをインストールして、運用中のイメージにCRITICALな脆弱性がないかをスキャンする
・今月中にやること: DockerfileにUSER指定を追加し、アプリを非rootで動かす構成に変更する
・次のスプリントでやること: CI/CDパイプラインにTrivyスキャンを組み込み、CRITICAL検出時はデプロイを自動停止させる

「全部いっぺんにできない」は正直なところです。ただし、--privileged の撤廃とTrivyスキャンの導入は、コストが低く効果が高いため、最優先で取り組む価値があります。

よくある誤解と注意点

【誤解1】「コンテナはVMと同じくらい安全」

コンテナはカーネルを共有しています。VMのようにハイパーバイザーで完全に隔離されているわけではないため、Dockerコンテナだけをセキュリティ境界と考えるのは危険です。ネットワークポリシー、ホストのファイアウォール、Linuxの権限管理と組み合わせて多層防御を構成してください。

【誤解2】「Docker Hubの公式イメージは安全」

公式イメージでも、古いベースイメージを使っている場合は既知の脆弱性を含むことがあります。Trivyでのスキャンは公式イメージにも必ず実施し、:latest タグに頼らず、バージョンを固定して管理するのがベストプラクティスです。

【誤解3】「コンテナを再起動すれば状態がリセットされる」

ボリュームマウントされたデータや外部ストレージ（データベース等）はコンテナの再起動後も残ります。コンテナ内での攻撃がホスト側ボリュームに及んだ場合、コンテナを破棄しても影響が残ることを理解してください。

【注意】Docker ComposeとKubernetesでも同じ原則が適用される

本記事ではDockerコマンドを例に挙げましたが、Docker Composeでは security_opt や cap_drop フィールドで同様の設定が可能です。Kubernetesでは SecurityContext と PodSecurityAdmission ポリシーで対応します。コンテナオーケストレーション環境でも同じ考え方を適用してください。

本記事のまとめ

Dockerコンテナのセキュリティ強化で対処すべき主な課題と対策をまとめます。

Dockerのセキュリティは「コンテナを動かしたら終わり」ではなく、継続的なスキャン・設定見直し・アップデートのサイクルが重要です。まず --privileged の排除とTrivyスキャンの導入から始め、段階的に強化の範囲を広げていきましょう。

ホストLinuxのseccompやcapabilitiesの詳細な仕組みについては、Linuxのseccomp入門およびLinuxのcapabilities入門もあわせてご覧ください。