メインコンテンツまでスキップ

Docker Compose と Ubuntu による安全なデプロイ

· 約 7 分

シリコンバレーのスタートアップでは、Docker Compose はコンテナ化アプリケーションを迅速にデプロイ・管理するための好まれるツールの一つです。しかし、利便性にはしばしばセキュリティリスクが伴います。Site Reliability Engineer（SRE）として、セキュリティ脆弱性が壊滅的な結果を招くことを痛感しています。本記事では、Docker Compose と Ubuntu を組み合わせた実務でまとめたベストなセキュリティ実践を共有し、Docker Compose の便利さを享受しつつシステムの安全性を確保する方法をご紹介します。

Docker Compose と Ubuntu による安全なデプロイ

I. Ubuntu システムのセキュリティ強化​

コンテナをデプロイする前に、Ubuntu ホスト自体のセキュリティを確保することが重要です。主な手順は以下の通りです。

1. Ubuntu と Docker を定期的にアップデート​

システムと Docker の両方を最新の状態に保ち、既知の脆弱性を修正します。

sudo apt update && sudo apt upgrade -y
sudo apt install docker-ce docker-compose-plugin

2. Docker 管理権限を制限​

Docker の管理権限を厳格にコントロールし、特権昇格攻撃を防止します。

sudo usermod -aG docker deployuser
# 一般ユーザーが簡単に Docker 管理権限を取得できないようにする

3. Ubuntu ファイアウォール (UFW) を設定​

ネットワークアクセスを適切に制限し、不正アクセスを防止します。

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

4. Docker と UFW の連携を適切に設定​

デフォルトでは Docker が iptables を直接操作し、UFW をバイパスします。手動で制御することを推奨します。

Docker 設定ファイルを編集します。

sudo nano /etc/docker/daemon.json

以下の内容を追加します。

{
  "iptables": false,
  "ip-forward": true,
  "userland-proxy": false
}

Docker サービスを再起動します。

sudo systemctl restart docker

Docker Compose でアドレスを明示的にバインドします。

services:
  webapp:
    ports:
      - "127.0.0.1:8080:8080"

II. Docker Compose のセキュリティベストプラクティス​

以下の設定は Docker Compose v2.4 以降を対象としています。Swarm モードと非 Swarm モードの違いに注意してください。

1. コンテナ権限を制限​

デフォルトで root で実行されるコンテナはリスクが高いため、非 root ユーザーに変更します。

services:
  app:
    image: your-app:v1.2.3
    user: "1000:1000" # 非 root ユーザー
    read_only: true # 読み取り専用ファイルシステム
    volumes:
      - /tmp/app:/tmp # 書き込みが必要なディレクトリだけマウント
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE

解説

  • 読み取り専用ファイルシステムはコンテナ内部での改ざんを防止します。
  • マウントするボリュームは必要最小限に留めます。

2. ネットワーク分離とポート管理​

内部ネットワークと外部ネットワークを明確に分離し、機密サービスが外部に露出しないようにします。

networks:
  frontend:
    internal: false
  backend:
    internal: true

services:
  nginx:
    networks: [frontend, backend]
  database:
    networks:
      - backend
  • frontend ネットワーク: 公開可。
  • backend ネットワーク: 完全に内部限定。

3. シークレット管理の安全化​

機密情報は Compose ファイルに直接記載しないでください。

単一マシンモードの場合:

services:
  webapp:
    environment:
      - DB_PASSWORD_FILE=/run/secrets/db_password
    volumes:
      - ./secrets/db_password.txt:/run/secrets/db_password:ro

Swarm モードの場合:

services:
  webapp:
    secrets:
      - db_password
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password

secrets:
  db_password:
    external: true # Swarm の組み込みシークレット管理を利用

注意

  • Docker Swarm のネイティブシークレットは Vault や AWS Secrets Manager など外部ツールを直接利用できません。外部シークレットストレージが必要な場合は、読み取り処理を自前で組み込む必要があります。

4. リソース制限（Compose バージョンに合わせて）​

コンテナがホストリソースを使い果たすのを防ぎます。

単一マシンモード（推奨 v2.4）:

version: "2.4"

services:
  api:
    image: your-image:1.4.0
    mem_limit: 512m
    cpus: 0.5

Swarm モード（v3 以上）:

services:
  api:
    deploy:
      resources:
        limits:
          cpus: "0.5"
          memory: 512M
        reservations:
          cpus: "0.25"
          memory: 256M

注記: 非 Swarm 環境では deploy セクションのリソース制限は 無効 です。Compose ファイルのバージョンに注意してください。

5. コンテナヘルスチェック​

ヘルスチェックを設定し、問題を早期に検知してサービス停止時間を短縮します。

services:
  webapp:
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 20s

6. latest タグの使用を避ける​

本番環境で latest タグを使用するとバージョン管理が曖昧になります。明示的にイメージバージョンを指定してください。

services:
  api:
    image: your-image:1.4.0

7. ログ管理の適切化​

コンテナログがディスク容量を圧迫しないように制限します。

services:
  web:
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "5"

8. Ubuntu の AppArmor 設定​

Ubuntu ではデフォルトで AppArmor が有効化されています。Docker のプロファイル状態を確認しましょう。

sudo systemctl enable --now apparmor
sudo aa-status

Ubuntu 上の Docker はデフォルトで AppArmor を有効にしますが、同時に SELinux を有効化すると競合するため推奨されません。

9. 継続的なアップデートとセキュリティスキャン​

  • イメージ脆弱性スキャン: CI/CD パイプラインに Trivy、Clair、Snyk などを組み込みます。
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
  aquasec/trivy image your-image:v1.2.3
  • 自動セキュリティアップデート: 既知の脆弱性を修正するため、少なくとも週に一度はイメージをリビルドします。

III. ケーススタディ：Docker Compose 設定ミスから得た教訓​

2019 年 7 月、Capital One は 1 億人以上の顧客情報が流出する大規模なデータ侵害を受けました12。主因は AWS 設定ミスでしたが、同時にコンテナのセキュリティ問題も関与していました。

  1. コンテナ権限の問題: 攻撃者は過剰な権限を持つ WAF コンテナの脆弱性を突きました。
  2. ネットワーク分離の不備: 侵害されたコンテナから他の AWS リソースへアクセスでき、ネットワーク分離が不十分でした。
  3. 機密データの露出: 設定ミスにより大量の顧客データが取得可能になっていました。
  4. セキュリティ設定ミスの蓄積: コンテナとクラウドサービスの設定エラーが重なり、重大なインシデントに繋がりました。

この事故により Capital One は数億ドル規模の罰金と長期的な信頼危機に直面しました。権限管理、ネットワーク分離、機密データ保護の重要性を改めて認識させる事例です。

IV. 結論と推奨事項​

Docker Compose と Ubuntu の組み合わせはコンテナアプリケーションを迅速にデプロイする便利な手段ですが、セキュリティはプロセス全体に組み込む必要があります。

  • コンテナ権限とネットワーク分離を厳格に管理する
  • 機密情報の漏洩を防止する
  • 定期的なセキュリティスキャンとアップデートを実施する
  • エンタープライズ規模になるほど、Kubernetes など高度なオーケストレーションへ移行し、セキュリティ保証を強化することを推奨します

セキュリティは終わりなき取り組みです。本記事が Docker Compose + Ubuntu 環境の保護に役立つことを願っています。

Share on Twitter