コンテナセキュリティは「後から」では遅い
Docker導入時にセキュリティを後回しにし、本番稼働後に脆弱性スキャンをかけて青ざめる。よくあるパターンだ。KGAでも過去にこの失敗を経験した。クライアントの本番コンテナイメージからCriticalレベルの脆弱性が47個検出され、緊急の全イメージ再ビルドを余儀なくされた。この経験から、KGAではコンテナセキュリティをCI/CDパイプラインの初期段階に組み込む「Shift Left」アプローチを徹底している。
ベースイメージの選択: ここで8割が決まる
セキュリティの大半はベースイメージの選択で決まる。ubuntu:latestやnode:20のようなフルイメージは、不要なパッケージが大量に含まれ、攻撃面（attack surface）が広い。KGAの推奨は以下の優先順位だ。
第一選択: distroless。Google提供の最小イメージで、シェルすら含まない。アプリケーションバイナリとランタイムのみ。攻撃者がコンテナに侵入しても、シェルがないためコマンド実行が困難。GoやJavaアプリに最適。
第二選択: Alpine Linux（3.19以降）。muslベースの軽量ディストリビューション。5MBの最小サイズ。ただしmuslとglibcの互換性問題に注意。Node.jsやPythonでネイティブモジュールを使う場合はビルド時の依存が増える。
第三選択: Debian slim。glibcベースの互換性が必要な場合。フルDebianの1/3程度のサイズ。Pythonの科学計算ライブラリ（numpy、pandas等）を使う場合はこちらが安定。
KGAの実測では、node:20（1.1GB）からnode:20-alpine（180MB）に変更するだけで、イメージ内の既知の脆弱性が312個から23個に減少した。
マルチステージビルドの徹底
ビルド時の依存関係を本番イメージに含めないことが鉄則だ。マルチステージビルドで、ビルドステージにコンパイラやdevDependenciesを配置し、最終ステージにはビルド成果物のみをコピーする。
Pythonの場合、pipの--user installと仮想環境をビルドステージで行い、最終ステージにsite-packagesディレクトリだけをコピーする。これにより、gcc、make、python-devなどのビルドツールが本番イメージから排除される。
Rootless Docker: ホストへの影響を最小化
Docker Engine自体をrootless modeで動作させることで、コンテナエスケープ時のホストへの影響を大幅に軽減できる。Docker 24以降でrootless modeは安定しており、KGAの開発環境ではすべてrootlessで運用している。
本番環境ではrootless Dockerに加え、コンテナ内のプロセスも非rootユーザーで実行する。DockerfileのUSERディレクティブでアプリケーション専用ユーザーを作成し、最小限の権限で実行する。
seccomp profileによるシステムコールの制限も有効だ。デフォルトのseccomp profileで約44のシステムコールがブロックされるが、カスタムprofileでアプリケーションが使用しないシステムコールをさらに制限できる。KGAではstrace -cでアプリケーションが使用するシステムコールを計測し、必要最小限のprofileを作成している。
イメージスキャンのCI/CD統合
KGAではTrivy（Aqua Security製のOSSスキャナ）をGitHub Actionsに統合している。PRごとにDockerイメージをビルドし、TrivyでCVEスキャンを実行。CriticalまたはHighの脆弱性が検出されたらPRをブロックする。
Trivyの設定としては、.trivyignoreファイルで誤検知やアプリケーションに影響しない脆弱性を除外リストに追加できる。ただし除外の判断は必ずセキュリティレビューを通すこと。KGAでは除外リストの変更にSecurityチームのapprovalを必須としている。
Snykも併用しており、ライセンスコンプライアンスのチェックと、より詳細な修正提案の取得に活用している。TrivyとSnykの組み合わせで、スキャンの網羅性を確保している。
ランタイムセキュリティ
イメージの静的スキャンだけでは不十分だ。実行時の異常な挙動を検知するランタイムセキュリティも重要。KGAではFalco（CNCF incubatingプロジェクト）をKubernetes環境にデプロイし、コンテナ内の不審なプロセス起動、ファイルアクセス、ネットワーク通信をリアルタイムで検知している。
Falcoのカスタムルール例として、「コンテナ内でのシェル起動を検知」「/etc/passwdへの書き込みを検知」「想定外のアウトバウンド通信を検知」などを設定している。アラートはSlackとPagerDutyに飛ばし、即座に対応する体制を構築した。
ネットワーク分離とシークレット管理
Docker Composeレベルでも、サービス間のネットワークを分離する。フロントエンド、バックエンド、データベースをそれぞれ別ネットワークに配置し、必要な通信のみを許可する。デフォルトのブリッジネットワークにすべてのコンテナを接続するのは避けるべきだ。
シークレット（APIキー、DBパスワード等）は絶対にDockerfileやdocker-compose.ymlにハードコードしない。Docker Secrets（Swarm mode）またはexternal secret management（HashiCorp Vault、AWS Secrets Manager等）を使用する。環境変数での受け渡しも、docker inspectで平文が見えるリスクがあるため、本番環境ではsecretマウントを推奨する。
KGAのセキュリティチェックリスト
最終的にKGAが全プロジェクトで適用しているチェックリストを共有する。ベースイメージはdistrolessまたはAlpineを使用。マルチステージビルドで不要な依存を排除。非rootユーザーでプロセスを実行。読み取り専用ファイルシステム（--read-only）の使用。ヘルスチェックの設定。リソース制限（CPU、メモリ）の設定。CI/CDでのイメージスキャン。ランタイム監視の導入。ネットワーク分離の実装。シークレットの安全な管理。このチェックリストをPRテンプレートに組み込み、毎回確認する運用を徹底している。