docker-security-guide

🚨 重大なガイドライン

Windows のファイルパス要件

必須：Windows ではファイルパスに必ずバックスラッシュを使用してください

Windows で Edit ツールまたは Write ツールを使用する場合、ファイルパスにはスラッシュ（/）ではなく、必ずバックスラッシュ（\）を使用してください。

例：

• ❌ 誤り：D:/repos/project/file.tsx
• ✅ 正しい：D:\repos\project\file.tsx

これは以下に適用されます。

• Edit ツールの file_path パラメーター
• Write ツールの file_path パラメーター
• Windows システムでのすべてのファイル操作

ドキュメント作成ガイドライン

ユーザーから明示的に依頼されない限り、新しいドキュメントファイルを作成しないでください。

• 優先事項： 新しいドキュメントを作成するのではなく、既存の README.md ファイルを更新してください
• リポジトリの整理： ユーザーから別途依頼がない限り、リポジトリのルートは README.md のみとし、整理された状態を保ってください
• スタイル： ドキュメントは簡潔で直接的、かつプロフェッショナルな表現にしてください。AI が生成したような文体は避けてください
• ユーザーの希望： ユーザーがドキュメント作成を明示的に依頼した場合に限り、追加の .md ファイルを作成してください

---

Docker セキュリティガイド

このスキルでは、脅威、緩和策、コンプライアンス要件を網羅し、すべてのプラットフォームに対応する Docker の包括的なセキュリティガイドラインを提供します。

セキュリティ原則

多層防御

複数の層でセキュリティ対策を適用します。

1. イメージセキュリティ： 最小限で、スキャン済みかつ署名されたイメージ
2. ビルドセキュリティ： 安全なビルドプロセス。レイヤーにシークレットを含めない
3. 実行時セキュリティ： 制限されたケイパビリティ、リソース制限
4. ネットワークセキュリティ： 分離、最小権限
5. ホストセキュリティ： 強化されたホスト OS、更新済みの Docker デーモン
6. オーケストレーションセキュリティ： 安全な設定、RBAC
7. 監視： 検出、ログ記録、アラート

最小権限

必要最小限の権限のみを付与します。

• 非 root ユーザー
• ケイパビリティの削除
• 読み取り専用ファイルシステム
• 最小限のネットワーク公開
• 制限されたシステムコール（seccomp）
• リソース制限

イメージセキュリティ

ベースイメージの選択

脅威： 脆弱または悪意のあるベースイメージ

緩和策：

# Use official images only
FROM node:20.11.0-alpine3.19  # Official, specific version

# NOT
FROM randomuser/node  # Unverified source
FROM node:latest      # Unpredictable, can break

検証：

# Verify image source
docker image inspect node:20-alpine | grep -A 5 "Author"

# Enable Docker Content Trust (image signing)
export DOCKER_CONTENT_TRUST=1
docker pull node:20-alpine

最小限のイメージ

脅威： 攻撃対象領域の拡大、脆弱性の増加

緩和策：

# Prefer minimal distributions
FROM alpine:3.19           # ~7MB
FROM gcr.io/distroless/static  # ~2MB
FROM scratch               # 0MB (for static binaries)

# vs
FROM ubuntu:22.04          # ~77MB with more packages

利点：

• パッケージが少ないほど、脆弱性も少なくなります
• 攻撃対象領域が小さくなります
• ダウンロードと起動が速くなります
• ディスク容量を節約できます

セキュリティが重要なアプリケーション向けマイクロディストリビューション（2025 年）

Wolfi/Chainguard イメージ：

• CVE ゼロを目標とし、SBOM がデフォルトで含まれます
• 毎晩セキュリティパッチが適用され、来歴情報付きで署名されます
• Node、Python、Go、Java、.NET などで利用できます

使用方法：

# Development stage (includes build tools)
FROM cgr.dev/chainguard/node:latest-dev AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

# Production stage (minimal, zero-CVE goal)
FROM cgr.dev/chainguard/node:latest
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
USER node
ENTRYPOINT ["node", "server.js"]

使用する場面： セキュリティが重要なアプリ、コンプライアンス要件（SOC2、HIPAA、PCI-DSS）、ゼロトラスト環境、サプライチェーンセキュリティを重視する場合。

イメージの比較表全体については、docker-best-practices スキルを参照してください。

脆弱性スキャン

ツール：

• Docker Scout（組み込み）
• Trivy
• Grype
• Snyk
• Clair

プロセス：

# Scan with Docker Scout
docker scout cves IMAGE_NAME
docker scout recommendations IMAGE_NAME

# Scan with Trivy
trivy image IMAGE_NAME
trivy image --severity HIGH,CRITICAL IMAGE_NAME

# Scan Dockerfile
trivy config Dockerfile

# Scan for secrets
trivy fs --scanners secret .

CI/CD との統合：

# GitHub Actions example
- name: Scan image
  run: |
    docker scout cves my-image:${{ github.sha }}
    trivy image --exit-code 1 --severity CRITICAL my-image:${{ github.sha }}

セキュリティを考慮したマルチステージビルド

脅威： ビルドツールやシークレットが最終イメージに残ること

緩和策：

# Build stage with build tools
FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN go build -o app

# Final stage - minimal, no build tools
FROM gcr.io/distroless/base-debian11
COPY --from=builder /app/app /
USER nonroot:nonroot
ENTRYPOINT ["/app"]

利点：

• 本番イメージにコンパイラーやビルドツールが含まれません
• ビルドで使用したシークレットが残りません
• 最終イメージを小さく、より安全にできます

ビルド時と実行時のセキュリティ

ビルドシークレット（--mount=type=secret、BuildKit）、マルチステージの強化、ケイパビリティの削除（--cap-drop=ALL）、seccomp / AppArmor プロファイル、読み取り専用ルート、ユーザー名前空間、リソース制限、rootless 実行に関する完全なレシピは references/build-runtime-security.md にあります。基本原則は以下のとおりです。

• ビルドシークレット： --mount=type=secret と --mount=type=ssh を使用し、機密情報に ARG/ENV は使用しないでください。
• 実行時： すべてのケイパビリティを削除し、必要なものだけを追加します。読み取り専用ルートと非 root ユーザーを使用し、リソースを制限し、イメージダイジェストを固定してください。
• プロファイル： seccomp、AppArmor、SELinux を適用し、ユーザー名前空間と組み合わせます。

すべてのコマンドとレシピについては、references/build-runtime-security.md を参照してください。

ネットワークセキュリティ

ネットワーク分離

脅威： コンテナ間の横方向の移動

緩和策：

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge
    internal: true  # No external access

services:
  web:
    networks:
      - frontend

  api:
    networks:
      - frontend
      - backend

  database:
    networks:
      - backend  # Isolated from frontend

ポートの公開

脅威： 不要なネットワークへの公開

緩和策：

# Bind to localhost only
docker run -p 127.0.0.1:8080:8080 my-image

# NOT (binds to all interfaces)
docker run -p 8080:8080 my-image

Compose での設定：

services:
  app:
    ports:
      - "127.0.0.1:8080:8080"  # Localhost only

コンテナー間通信

# Disable default inter-container communication
# /etc/docker/daemon.json
{
  "icc": false
}

次に、ネットワーク経由で明示的に許可します：

services:
  app1:
    networks:
      - app-network
  app2:
    networks:
      - app-network  # Can communicate with app1

networks:
  app-network:
    driver: bridge

シークレット管理

Docker Secrets（Swarm モード）

# Create secret
echo "mypassword" | docker secret create db_password -

# Use in service
docker service create \
  --name my-service \
  --secret db_password \
  my-image

# Access in container at /run/secrets/db_password

スタックファイルでの設定：

version: '3.8'

services:
  app:
    image: my-image
    secrets:
      - db_password

secrets:
  db_password:
    external: true

シークレットのベストプラクティス

1. 環境変数に絶対に含めない（docker inspect で表示されます）
2. イメージに絶対に含めない（レイヤーの履歴に残ります）
3. バージョン管理に絶対に含めない（Git の履歴に残ります）
4. アクセス許可を制限してファイルとしてマウントする
5. シークレット管理システムを使用する（Vault、AWS Secrets Manager など）
6. 定期的にローテーションする

代替策：マウントしたシークレット：

docker run -v /secure/secrets:/run/secrets:ro my-image

コンプライアンスとベンチマーク

CIS Docker ベンチマーク

自動チェック：

# Clone docker-bench-security
git clone https://github.com/docker/docker-bench-security.git
cd docker-bench-security
sudo sh docker-bench-security.sh

# Or run as container
docker run --rm --net host --pid host --userns host \
  --cap-add audit_control \
  -v /var/lib:/var/lib:ro \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -v /usr/lib/systemd:/usr/lib/systemd:ro \
  -v /etc:/etc:ro \
  docker/docker-bench-security

主な CIS 推奨事項

1. ホストの設定

   • Docker を最新の状態に保つ
   • コンテナー間のネットワークトラフィックを制限する
   • ロギングレベルを「info」に設定する
   • Docker Content Trust を有効にする

2. Docker デーモン

   • Docker デーモンソケットに TLS を使用する
   • TLS なしでデーモンを TCP に公開しない
   • ユーザー名前空間のサポートを有効にする

3. Docker ファイル

   • Docker ファイルの所有権とアクセス許可を確認する
   • Docker ファイルとディレクトリを監査する

4. コンテナーイメージ

   • コンテナー用のユーザーを作成する
   • 信頼できるベースイメージを使用する
   • 不要なパッケージをインストールしない

5. コンテナーランタイム

   • 権限を制限してコンテナーを実行する
   • リソース制限を設定する
   • ホストのネットワーク名前空間を共有しない

モニタリングと検出

ロギング

services:
  app:
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"
        labels: "service,env"
        env: "ENV,VERSION"

一元化されたロギング：

services:
  app:
    logging:
      driver: "syslog"
      options:
        syslog-address: "tcp://log-server:514"
        tag: "{{.Name}}/{{.ID}}"

ランタイムモニタリング

ツール：

• Falco：ランタイムセキュリティのモニタリング
• Sysdig：コンテナーの可視化
• Prometheus + cAdvisor：メトリクス
• Docker events：リアルタイムイベント

次の項目を監視します：

• 想定外のプロセス
• ファイルの変更
• ネットワーク接続
• リソースの急増
• 認証の失敗
• 権限昇格の試み

# Monitor Docker events
docker events --filter 'type=container' --filter 'event=start'

# Watch specific container
docker events --filter "container=my-container"

# Runtime security with Falco
docker run --rm -it \
  --privileged \
  -v /var/run/docker.sock:/host/var/run/docker.sock \
  -v /dev:/host/dev \
  -v /proc:/host/proc:ro \
  falcosecurity/falco

プラットフォーム固有のセキュリティ

Linux

ユーザー名前空間の再マッピング：

// /etc/docker/daemon.json
{
  "userns-remap": "default"
}

利点：コンテナー内の root → ホスト上では非特権ユーザー

SELinux：

# Enable SELinux for Docker
setenforce 1

# Run with SELinux labels
docker run --security-opt label=type:svirt_sandbox_file_t my-image

# Volumes with SELinux
docker run -v /host/path:/container/path:z my-image

AppArmor：

# Check AppArmor status
aa-status

# Run with AppArmor profile
docker run --security-opt apparmor=docker-default my-image

Windows

Hyper-V 分離：

# More isolated than process isolation
docker run --isolation=hyperv my-image

Windows Defender：

• リアルタイム保護が有効になっていることを確認する
• 除外設定を慎重に行う
• イメージを定期的にスキャンする

macOS

Docker Desktop のセキュリティ：

• Docker Desktop を最新の状態に保つ
• 「Use gRPC FUSE for file sharing」を有効にする
• ファイル共有を必要なパスに限定する
• リソース割り当てを確認する

セキュリティチェックリスト

イメージ：

• 公式の最小限のイメージをベースにしている
• 特定のバージョンタグを使用している（latest ではない）
• 脆弱性をスキャン済み
• レイヤーにシークレットが含まれていない
• root 以外のユーザーとして実行される
• 署名済み（Content Trust）

ビルド：

• .dockerignore を設定済み
• マルチステージビルドを使用している（該当する場合）
• ビルドシークレットを適切に扱っている
• 信頼できるソースのみからビルドしている

ランタイム：

• root 以外のユーザーを使用している
• ケイパビリティを削除済み
• 読み取り専用ファイルシステムを使用している（可能な場合）
• セキュリティオプションを設定済み
• リソース制限を設定済み
• ネットワークを分離済み
• ポートの公開を最小限にしている
• シークレットを安全にマウントしている

運用：

• CIS ベンチマークに準拠している
• ロギングを設定済み
• モニタリングを導入済み
• 脆弱性スキャンを定期的に実施している
• インシデント対応計画を策定済み
• 定期的に更新している
• 監査ログを有効にしている

よくあるセキュリティ上の誤り

❌ 絶対にしないでください：

• root として実行する
• --privileged を使用する
• Docker ソケット（/var/run/docker.sock）をマウントする
• シークレットをハードコードする
• latest タグを使用する
• 脆弱性スキャンを省略する
• 不要なポートを公開する
• セキュリティ機能を無効にする
• セキュリティアップデートを無視する
• 検証されていないイメージを信頼する

✅ 必ず実施してください：

• root 以外のユーザーとして実行する
• ケイパビリティを削除する
• 脆弱性をスキャンする
• シークレット管理を使用する
• 特定のバージョンでタグ付けする
• セキュリティオプションを有効にする
• 最小権限を適用する
• システムを最新の状態に保つ
• 実行時の動作を監視する
• 公式イメージを使用する

このセキュリティガイドは、現在のベストプラクティスをまとめたものです。セキュリティ上の脅威は絶えず進化するため、Docker の最新のセキュリティドキュメントと CVE データベースを必ず確認してください。