コンテナ・Kubernetes セキュリティ

コンテナと Kubernetes はクラウドネイティブ開発を加速した一方、新たな攻撃面を生み出した。4C モデル（Cloud / Cluster / Container / Code） はこの攻撃面を層別に整理するフレームワークだ。イメージスキャン・ランタイム監視・クラスタハードニング・サプライチェーン保護を組み合わせることで、コードから本番実行まで一貫した防御を実現する。情報カットオフ ~2025-08、confidence: medium 固定。

コンテナ・Kubernetes の攻撃面と 4C モデル

4C モデルはコンテナ環境のセキュリティレイヤーを 4 つに分類する。

レイヤー	範囲	代表的なリスク
Cloud	IaaS・ネットワーク・IAM	責任共有モデルの誤解、公開 API、過剰権限
Cluster	Kubernetes コントロールプレーン・ワーカーノード	kube-apiserver の公開、etcd 暗号化欠如、RBAC 過剰権限
Container	コンテナイメージ・ランタイム	脆弱イメージ、root 実行、特権コンテナ
Code	アプリケーションコード・依存ライブラリ	アプリ脆弱性、シークレットのハードコード、サードパーティライブラリ

外側のレイヤー（Cloud）のリスクが高いほど、内側の防御が無効化される。4C は依存関係ではなく「積み重ねの防御」であり、各レイヤーで独立して対策が必要だ。

イメージスキャン（Shift-Left セキュリティ）

コンテナイメージは出発点となるビルドアーティファクトだ。脆弱なイメージが本番に到達する前に CI 段階で検知・遮断する「Shift-Left」が基本方針となる。

主なスキャンツール：

Trivy（Aqua Security 製）：OS パッケージ・言語依存ライブラリ・Dockerfile ミス・シークレットを検知。軽量で CI 統合が容易。
Grype（Anchore 製）：SBOM との親和性が高い。
Clair（CoreOS 起源）：レジストリ連携での継続スキャン。

最小ベースイメージ：debian:bullseye より distroless や alpine を使うことで攻撃面を大幅に縮小できる。distroless はシェルすら含まないため、コンテナブレイクアウト後の横展開が困難になる。

シークレット検出：環境変数や Dockerfile の RUN コマンドにハードコードされた認証情報は gitleaks / Trivy の secret スキャンで検知できる。CI でブロックする仕組みが必須だ。

CI/CD セキュリティとの連携については tech-142 を参照。

ランタイム防御

デプロイ後のコンテナが予期しない挙動をしていないかを監視するのがランタイム防御だ。

Falco（CNCF プロジェクト）：カーネルシステムコールをリアルタイムで監視し、異常なプロセス起動・ファイルアクセス・ネットワーク接続を検知してアラートを発する。ルールは YAML で定義可能。

eBPF（extended Berkeley Packet Filter）：カーネルモジュールを使わずにカーネルレベルの観測が可能なアーキテクチャ。Falco 自体も eBPF ドライバーに移行しており、Cilium や Tetragon も eBPF を活用したランタイム可視化を提供する。

ドリフト検知：本番コンテナへの想定外の変更（ファイル書き換え・バイナリ追加）を検知して封じ込める。イミュータブルインフラの原則を実行時に強制する機能だ。

ランタイム異常の検知後は、問題のある Pod を隔離しネットワークポリシーで封じ込めることが標準的な対応フローになる。

クラスタハードニング

Kubernetes クラスタ自体のセキュリティ設定は多岐にわたる。

Pod Security Standards（PSS）：Kubernetes 1.25 で GA となった Pod セキュリティポリシーの後継。privileged・baseline・restricted の 3 レベルで Pod の権限を制限する。restricted プロファイルでは root 実行・特権コンテナ・hostNetwork 等が禁止される。

Admission Control：Pod がクラスタに受け入れられる前に検査・変更・拒否するフック機構。

OPA/Gatekeeper：Open Policy Agent ベース。Rego 言語でポリシーを定義し、不適合な Pod を拒否できる。
Kyverno：Kubernetes ネイティブなポリシー言語。イメージ署名の検証も担える。

RBAC（Role-Based Access Control）：サービスアカウントへの過剰権限付与が侵害時の横展開経路になる。cluster-admin の乱用を避け、最小権限の原則を各 Namespace に適用する。

ネットワークポリシー：デフォルトでは全 Pod 間が通信可能。NetworkPolicy リソースで「必要な通信のみ許可」するホワイトリスト方式に切り替える。Cilium などの CNI プラグインがより高度な L7 ポリシーを提供する。

シークレット管理：Kubernetes Secret は base64 エンコードであり暗号化ではない。etcd の保存時暗号化（Encryption at Rest）を有効化するか、HashiCorp Vault や AWS Secrets Manager などの外部シークレットストアと統合する（External Secrets Operator 等）。

サプライチェーン保護

コンテナのサプライチェーン（ベースイメージ → ビルド → レジストリ → デプロイ）を改ざんから守る取り組みが SLSA（Supply-chain Levels for Software Artifacts）や Sigstore によって推進されている。

イメージ署名：Cosign（Sigstore）を使ったイメージの署名・検証。Kyverno や Gatekeeper で署名済みイメージのみ受け入れるポリシーを強制できる。

SBOM（Software Bill of Materials）：コンテナに含まれる全ソフトウェアコンポーネントのリスト。Trivy・Syft などで生成し、CVE 情報と突き合わせて継続的に評価する。SBOM の詳細と VEX との組み合わせについては tech-140 を参照。

信頼できるレジストリ：公開レジストリ（Docker Hub）の野良イメージは検証が難しい。組織内のプライベートレジストリ（Amazon ECR / Azure Container Registry / Google Artifact Registry）に限定し、承認済みイメージのみ使用するポリシーを admission control で強制する。

アンチパターン一覧

#	アンチパターン	リスク	対策
1	イメージスキャンなしで本番へ投入	既知 CVE のある脆弱イメージが稼働	CI 段階での Trivy / Grype スキャン＋重大度による CI ブロック
2	root ユーザーでコンテナを実行	コンテナブレイクアウト時にホストへ侵害拡大	Dockerfile で `USER` 指定・PSS restricted 適用
3	Admission Control を設定せず野良 Pod を許可	ポリシー外のコンテナが動作	OPA/Gatekeeper または Kyverno でベースラインポリシーを施行
4	RBAC でサービスアカウントに cluster-admin を付与	侵害 Pod が全クラスタを制御可能に	最小権限 Role + 定期棚卸し
5	ランタイム監視なしで本番運用	侵害・異常動作が検知されない	Falco 導入＋アラートの SIEM 連携
6	Kubernetes Secret を暗号化せず etcd へ保存	etcd 漏洩でシークレット全露出	etcd Encryption at Rest ＋外部シークレットストア

Container and Kubernetes Security（コンテナ・Kubernetes セキュリティ）