コンテナ・セキュリティの体系化: 2026年時点における攻撃面、検知制御、ゼロトラスト運用、そしてクラウドネイティブ防御の実践的研究

1. Introduction

コンテナは、2026年時点でアプリケーション配備の標準的な抽象化単位となり、マイクロサービス、AI/ML パイプライン、エッジ計算、内部開発基盤、さらには規制対応が厳しい金融・医療・政府系ワークロードにまで浸透している。コンテナ化は従来の仮想マシンよりも軽量で高速な展開を可能にするが、その代償として、OS カーネル共有、イメージ再利用、分散レジストリ、広域オーケストレーション、CI/CD 自動化という新しい信頼境界が生まれる。結果として、コンテナのセキュリティは単一の隔離機構ではなく、ソフトウェア供給網、実行基盤、ネットワーク、アイデンティティ、監査、復旧を含む複合工学問題となった。

この複合性のため、コンテナへの攻撃はもはや単純な「root を取る」問題ではない。実務では、まず不正イメージがレジストリに混入し、次に Admission Controller の抜け穴を突いて Kubernetes 上で起動し、その後に過剰権限の ServiceAccount、マウントされた Docker socket、過大な capability、あるいは未修正のランタイム欠陥を足掛かりに横展開する、という連鎖的な侵害が一般的である。攻撃者はまた、ログ収集サイドカー、CI のシークレット、クラウドメタデータサービス、node 向けの特権 DaemonSet、あるいは egress 制御の甘いポッドを利用して、クラスタ外の資産へ到達する。したがって、コンテナ防御は「コンテナ単体」を見るだけでは不十分であり、クラウドネイティブ・スタック全体を監視・制御する必要がある。

2026年時点では、ゼロトラスト、SRE、CNAPP、eBPF、SBOM、署名検証、SLSA、ポリシー・アズ・コードが成熟し、理論的提案から実運用の標準へ移行している。しかし、導入しただけでは安全にならない。たとえば、SBOM は可視化を提供するが、脆弱性の優先順位付けが不適切であればノイズを増やすだけである。Admission Policy は強力だが、例外運用が増えると形骸化する。eBPF ベースのランタイム検知は高い観測能力を持つ一方、テレメトリの粒度が高すぎるとコスト増と誤検知につながる。したがって、必要なのは技術の寄せ集めではなく、脅威モデルと運用制約を前提にした統合設計である。

本稿の目的は、コンテナ・セキュリティを2026年時点の実務に即して体系化し、攻撃面の分類、脅威モデル、実装可能な防御アーキテクチャ、評価方法、運用上の限界を一体として提示することにある。特に、コンテナ・ランタイムの脆弱性、Kubernetes 制御面の権限過多、イメージ・サプライチェーン汚染、秘密情報の取り扱い不備、ネットワーク分離の失敗、そしてクラウド・アイデンティティの連携不全を横断的に扱う。研究上の焦点は「どの制御をどの順序で適用すれば、侵害確率と被害半径を最小化できるか」であり、単なるベストプラクティスの羅列ではない。

本稿の主張は明確である。第一に、コンテナ防御はレイヤごとではなく侵害チェーンごとに設計すべきである。第二に、検知と予防は対立概念ではなく、Admission、Runtime、Identity、Network の四層で同期すべきである。第三に、クラウドネイティブ環境における最小権限は、ポリシー設定だけでは達成できず、継続的な観測、再評価、例外の収束を必要とする。第四に、2026年の脅威環境では、AI を用いたフィッシング、秘密情報収集、脆弱性探索、ポリシー回避も実戦的であり、防御側も同等の自動化と検証を必要とする。

2. Background and Related Work

コンテナの基礎は Linux のプロセス隔離機構にある。名前空間は PID、NET、MNT、UTS、IPC、USER の各視点を分離し、cgroup は CPU、メモリ、I/O、PID 数を制限する。さらに、Linux capability は従来の全権 root を細分化し、seccomp はシステムコール面の制約を与える。AppArmor と SELinux は MAC による追加制御を提供し、Landlock はユーザ空間主体の制限を補完する。コンテナ・ランタイムとしては、2026年時点で containerd、CRI-O、runc、crun が主要な選択肢であり、Kubernetes は依然として事実上の標準オーケストレータである。これらの要素が組み合わさることで、コンテナは「軽量な仮想化」以上の意味を持つようになった。

理論的には、コンテナはカーネル共有を伴うため、VM よりも逃避リスクが高いと考えられる。実務的には、ほとんどの侵害はカーネル欠陥そのものよりも、誤設定、権限過多、秘密情報漏えい、脆弱イメージ、レジストリの不正混入、そして運用上の例外から生じる。CVE-2019-5736 は runc の実行ファイル上書きによってコンテナ逃避が可能であることを広く知らしめた。CVE-2022-0847 の Dirty Pipe は、条件次第で読み取り専用ファイルの改変を可能にし、コンテナ・ホスト境界の脆弱性認識を再強化した。CVE-2022-0492 は cgroup release_agent と CAP_SYS_ADMIN の危険な組合せを再び可視化した。CVE-2024-21626 は runc における file descriptor の取り扱い不備を通じ、実行時の境界維持がいかに繊細であるかを示した。これらは、コンテナがカーネルとランタイムの安全性に依存する以上、継続的なパッチ適用と強い権限縮小が不可欠であることを裏付ける。

一方、オーケストレーション層の関連研究は、Kubernetes の RBAC、Pod Security Admission、NetworkPolicy、ResourceQuota、LimitRange、Secret 管理、Admission Webhook、そして Service Mesh のセキュリティに集中してきた。RBAC は権限委譲を精密化するが、* ワイルドカードや過剰な verbs は即座にリスクとなる。Pod Security Admission は privileged、baseline、restricted の三段階で基本線を示すが、特権ポッドを必要とする監視やストレージ系コンポーネントには例外設計が必要である。NetworkPolicy は東西トラフィック制御に有効だが、CNI 実装差やクラスタ内 DNS、ノードローカル通信の扱いに注意が必要である。Cilium のような eBPF ベースのネットワーク・セキュリティは L3/L4 に加え、L7 可視化も提供し、実運用で重要性を増している。

サプライチェーン分野では、SBOM、署名、再現可能ビルド、依存関係固定、SLSA、in-toto、Sigstore が関連研究の中心である。Syft と Grype はイメージの構成把握と脆弱性照合を実用化し、Cosign は透明性ログ連携を含む署名検証を一般化した。SLSA はビルド工程の信頼度を段階化し、provenance を使って成果物の由来を証明する。これらはコンテナ環境における「どのイメージがどこでどう作られたか」を機械的に証明するための土台となる。しかし、SBOM と署名だけでは悪意ある正規利用者、侵害済みビルド基盤、あるいは依存ライブラリ内のロジック爆弾を防ぎ切れないため、制御面監査とランタイム監視が不可欠である。

運用検知の分野では、Falco がシステムコール・イベントのルールベース検知を広く普及させ、Tetragon や同系の eBPF 可観測性ツールがプロセス、ネットワーク、ファイル、資格情報アクセスをより低オーバーヘッドで可視化するようになった。KubeArmor は LSM と連携してポリシー適用を実施し、Cilium はネットワーク制御と観測を統合する。これらのツールは、従来の EDR をコンテナと Kubernetes に適合させるための重要なブリッジである。ただし、イベント粒度が高いほど良いわけではなく、通知過多は SOC の疲弊を招く。したがって、検知精度、運用可能性、封じ込め時間の最適化が重要な研究課題となる。

表1は、コンテナ防御に関与する主要技術の役割を整理したものである。

技術/機構	主要目的	長所	制約
名前空間/cgroup	プロセス・資源分離	軽量で標準的	カーネル共有に依存
capability/seccomp	権限縮小・syscall制限	細粒度制御	誤設定に弱い
AppArmor/SELinux	MAC 強制	逸脱抑止	導入・保守負荷
Pod Security Admission	Pod 基本制約	既定値の強化	例外運用が課題
OPA Gatekeeper/Kyverno	ポリシー・アズ・コード	一貫性と監査性	ルール設計が必要
Falco/Tetragon	ランタイム検知	実行時可視化	ノイズ管理が必要
Syft/Grype/Trivy	SBOM・脆弱性管理	供給網可視化	優先度付けが必要
Cosign/Sigstore	署名検証	由来保証	鍵管理が重要
Cilium/eBPF	ネットワーク・観測	高性能・高可視性	カーネル依存

3. Threat Model and Problem Formalization

本稿では、脅威をコンテナ単体ではなく、イメージ、制御面、実行面、サプライチェーンの結合システムとして定義する。攻撃者の目的は、$C$ を機密情報、$A$ を可用性、$I$ を完全性としたとき、少なくとも一つの資産に重大な影響を与えることである。被害関数を $$\mathcal{L} = \alpha C + \beta I + \gamma A$$ とおき、組織ごとに $\alpha, \beta, \gamma$ を調整する。金融では機密性重視、製造では可用性重視、AI/ML ではモデル完全性とデータ汚染耐性が重要になる。

攻撃者能力は次の四段階に分類できる。第一段階は外部露出面の探索であり、公開レジストリ、CI ログ、Git リポジトリ、過剰公開された Kubernetes API、誤設定された dashboard が対象となる。第二段階は初期実行であり、悪性イメージ、依存サプライチェーン汚染、コード実行を伴う設定注入、あるいは Web アプリ脆弱性経由でポッド内へ侵入する。第三段階は特権昇格および横展開であり、過剰 capability、hostPath、privileged、/var/run/docker.sock、hostNetwork、hostPID、hostIPC、または既知のランタイム脆弱性を利用する。第四段階は持続化と外部流出であり、DaemonSet、CronJob、Admission Webhook、ImagePullSecret、クラウド API 経由の永続的なアクセスが使われる。

この問題を形式化するため、各制御点 $k$ に対する攻撃成功確率を $p_k$、被害インパクトを $I_k$ とすると、総合リスクは $$R = \sum_{k=1}^{n} p_k \cdot I_k \cdot w_k$$ と表現できる。ここで $w_k$ は組織の重み付けである。防御目標は $R$ を閾値 $R_{max}$ 未満に抑えることであり、そのためには予防制御と検知制御の組合せが必要である。予防制御は $p_k$ を下げ、検知制御は $I_k$ の実効値を縮小する。封じ込め時間を $T_c$、検知遅延を $T_d$ とすれば、被害期待値は $$E[L] \approx \lambda \cdot (T_d + T_c) \cdot \bar{I}$$ で近似できる。したがって、検知を早めるだけでなく、封じ込めを自動化することが重要となる。

本稿の脅威モデルでは、クラスタ管理者の一部が善意だが誤設定する可能性も考慮する。実際のインシデントの多くは悪意ある高度攻撃者だけでなく、運用ミス、テンプレートの再利用、緊急時の一時的な権限付与から発生する。したがって、脅威モデルは外部攻撃者、内部不正、サプライチェーン汚染、そして誤設定を同時に扱う。さらに、AI を用いた攻撃支援として、フィッシング文面の生成、脆弱性探索の自動化、クラウド設定の推測、ポリシー文面の回避探索も含める必要がある。

表2は、本稿が対象とする主要脅威と、それに対する代表的制御を整理したものである。

脅威	典型ベクトル	主な影響	有効な制御
悪性イメージ	レジストリ汚染、タグ上書き	初期侵入	署名検証、SBOM、Trusted Registry
権限過多ポッド	privileged, hostPath, capability	逃避・横展開	PSA、OPA/Kyverno、最小権限
ランタイム脆弱性	runc/containerd/カーネル	ホスト侵害	パッチ管理、seccomp、隔離
Secret 漏えい	環境変数、マウント、CI ログ	資格情報窃取	外部 Secret 管理、監査
ネットワーク逸脱	Egress 制御不備	C2、流出	NetworkPolicy、Cilium、DNS監査
制御面侵害	Kubernetes API/RBAC	クラスタ掌握	RBAC 最小化、MFA、監査ログ

4. Proposed Methodology

本稿が提案する方法論は、コンテナを中心にした四面防御モデルである。第一面は Supply Chain Gate であり、ビルド成果物の真正性と構成を保証する。第二面は Admission Gate であり、Kubernetes への投入時にポリシー適合性を確認する。第三面は Runtime Gate であり、起動後のプロセス、システムコール、ファイル、ネットワーク、権限を監視する。第四面は Identity and Egress Gate であり、サービス間認証、秘密情報保護、アウトバウンド通信制御を担う。これらを独立ではなく連結した制御系として扱うことで、単一制御の失敗を他層で吸収する。

まず Supply Chain Gate では、ソースコードからイメージまでの流れを SLSA に沿って段階化し、ビルド環境を再現可能かつ隔離されたものにする。Syft で SBOM を生成し、Grype または Trivy で既知脆弱性を照合する。Cosign を用いてイメージと provenance に署名し、レジストリでは署名必須・未署名拒否を徹底する。ここで重要なのは、脆弱性の数ではなく、実行経路上の到達可能性である。すなわち、CVSS の高低だけでなく、コンテナ内でその脆弱性が実際に悪用可能かを判定する必要がある。これにより、無関係なノイズを減らし、重大な依存関係のみを優先できる。

次に Admission Gate では、Pod Security Admission を基準ラインとして、OPA Gatekeeper または Kyverno で組織固有の制約を追加する。たとえば、hostNetwork: true、hostPID: true、privileged: true、allowPrivilegeEscalation: true、CAP_SYS_ADMIN、未制限の hostPath、および未署名イメージを禁止する。例外を必要とするシステム・コンポーネントについては namespace 単位の許可ではなく、明示的な例外 CRD と有効期限を持たせる。これにより、永続的な「例外の恒久化」を防止する。Admission は一度通れば終わりではなく、定期的な再評価で drift を検出することが重要である。

Runtime Gate では、Falco と Tetragon を中核に据える。Falco はルールベースで可搬性が高く、Tetragon は eBPF を用いてプロセス、ネットワーク、ファイル、Kubernetes イベントを深く観測できる。両者を併用し、Falco で広い検知、Tetragon で高忠実度の追跡を行う。ポリシーは「最初の数分で何が起きるか」に焦点を当てる。具体的には、シェル起動、/proc や /sys への異常アクセス、/var/run/docker.sock への接続、setns、mount、ptrace、暗号通貨マイニング特有の CPU パターン、外部 C2 への異常 egress をルール化する。ランタイム検知の目的は単なるアラートではなく、自動隔離、ラベル付け、ネットワーク遮断、Pod 再作成停止につなげることである。

Identity and Egress Gate では、Kubernetes ServiceAccount、クラウド IAM、Workload Identity、サービスメッシュ mTLS、DNS ログ、Egress Gateway を統合する。目標は、ポッドが外部に出る経路を明示化し、不要な到達性を消すことである。クラスタ内サービスは mTLS で相互認証し、外向き通信は allowlist に限定する。Secret は環境変数ではなく、短命トークンと外部 Secret 管理基盤から動的注入する。クラウドメタデータサービスへの到達は原則遮断し、必要な場合はワークロード ID ベースに限定する。

定量評価のため、検知品質は Precision、Recall、F1 で測る。ここで $$Precision = \frac{TP}{TP+FP}, \quad Recall = \frac{TP}{TP+FN}, \quad F1 = \frac{2PR}{P+R}$$ とする。封じ込め性能は平均 $T_d$ と $T_c$ で、運用負荷は1日あたりのアラート件数、例外申請件数、手動対応時間で評価する。理想的な防御は「高検知・低誤検知・低負荷」だが、実際にはトレードオフがあるため、用途に応じて重みを変える必要がある。

次のコードブロックは、署名付きイメージの検証と脆弱性スキャンを CI に組み込む例である。

#!/usr/bin/env bash
set -euo pipefail

IMAGE="registry.example.com/payments/api:1.8.3"
DIGEST_IMAGE="registry.example.com/payments/api@sha256:3b7f..."

cosign verify --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity "https://github.com/org/repo/.github/workflows/build.yml@refs/heads/main" \
  "$DIGEST_IMAGE"

syft "$DIGEST_IMAGE" -o cyclonedx-json > sbom.json

trivy image --ignore-unfixed --severity HIGH,CRITICAL \
  --format json --output trivy.json "$DIGEST_IMAGE"

grype sbom:sbom.json --fail-on high

次のコードブロックは、Kubernetes Admission Policy の一例である。実運用では Gatekeeper の ConstraintTemplate または Kyverno Policy として管理する。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restricted-pod-hardening
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: disallow-privileged-and-host-mounts
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "privileged, hostNetwork, hostPID, hostPath, and CAP_SYS_ADMIN are prohibited"
        pattern:
          spec:
            =(hostNetwork): "false"
            =(hostPID): "false"
            containers:
              - securityContext:
                  =(privileged): "false"
                  =(allowPrivilegeEscalation): "false"
                  capabilities:
                    drop:
                      - "ALL"

5. Implementation

実装アーキテクチャは、ビルド、投入、実行、観測の四段構成である。ビルド段では、CI がソースを受け取り、依存関係を固定し、再現可能ビルドを行い、SBOM と provenance を生成する。ここで重要なのは、ビルド環境そのものを隔離し、署名鍵をビルドジョブから分離することである。たとえば、GitHub Actions、GitLab CI、Tekton、Argo Workflows のいずれを使う場合も、OIDC ベースの短命認証を用い、静的な長期 Secret を避けるべきである。

投入段では、kubectl apply 以前にポリシー適合性を検証する。kubeconform、kube-score、polaris、kubescape を組み合わせて、マニフェストの静的欠陥を検出する。Pod Security Admission を namespace に適用し、restricted を既定とする。ここで namespace ごとの緩和は極力避け、必要な例外は ServiceAccount 単位で限定する。クラウドネイティブ実務では、開発用 namespace の設定が本番へコピーされる事故が多いため、テンプレート化された例外の拡散を阻止する仕組みが不可欠である。

実行段では、ノードのハードニングが基本となる。最小権限の containerd 設定、runc/crun の更新、seccompProfile: RuntimeDefault、読み取り専用ルートファイルシステム、runAsNonRoot: true、capabilities.drop: ["ALL"] を標準とする。必要に応じて AppArmor または SELinux を有効化し、特権コンテナを例外化する。ストレージは hostPath を避け、CSI ボリュームや短命ストレージを使う。/var/run/docker.sock の露出は極めて危険であり、もし互換理由で必要なら、別のビルド・ランタイムに置換する。これにより、コンテナからホストへの直接的な制御経路を遮断できる。

観測段では、Falco、Tetragon、Cilium、Prometheus、Loki、OpenTelemetry を連携する。システムコール、プロセス起動、ネットワークセッション、Kubernetes API 操作、Secret 読み取りイベントを相関分析し、脆弱性スキャン結果や変更管理情報と結合する。たとえば、kubectl exec が深夜に本番 Pod に対して発生し、その直後に /bin/sh と curl が呼ばれ、さらに未知の外部 IP へ egress した場合、即時隔離ルールを発火させる。検知後は、ワークロードの削除だけでなく、関連 ServiceAccount の無効化、ネットワークポリシーの適用、Node の隔離、証跡保存を自動化する。

表3は、主要防御機構の実装上の位置付けを比較したものである。

防御機構	導入位置	主な効果	運用上の注意
SBOM + 署名	CI/CD, Registry	供給網の真正性保証	鍵管理と再署名
PSA + Admission Policy	API Server	不適切 Pod の遮断	例外の抑制
seccomp/AppArmor/SELinux	Node/Runtime	逃避・乱用抑制	アプリ適合性
Falco/Tetragon	Runtime	挙動検知	ルールの調整
NetworkPolicy/Cilium	Network	横展開と C2 抑止	DNS/サービス検討
Secret Manager	Identity	資格情報保護	ローテーション

6. Experimental Evaluation

評価は、実環境を模した Kubernetes クラスタ上で行う想定で設計した。評価対象は、権限過多 Pod、脆弱イメージ、ランタイム逸脱、秘密情報収集、外向き通信の5種類である。各シナリオに対し、従来の静的チェックのみ、Admission まで適用、Runtime 監視まで適用、そして四面防御を適用した場合を比較する。評価指標は、検知率、誤検知率、平均封じ込め時間、運用工数、実行オーバーヘッドである。

実験設計では、攻撃イベント数を $N$ とし、真陽性 $TP$、偽陽性 $FP$、偽陰性 $FN$ を集計する。検知品質は前述の Precision/Recall/F1 に加えて、封じ込め時間の中央値 $m(T_c)$ と p95 も測定する。実行オーバーヘッドは、CPU 増分 $\Delta CPU$、メモリ増分 $\Delta Mem$、ネットワーク遅延増分 $\Delta RTT$ として測る。クラウドネイティブ環境では、セキュリティ機構自体が性能劣化の原因になりうるため、機能の有効性だけでなくコストも評価対象である。

表4は、代表的なシナリオ別の検知結果の例である。

シナリオ	静的チェックのみ	Admission 併用	Runtime 併用	四面防御
privileged Pod 起動	低	高	高	高
/var/run/docker.sock 利用	なし	高	高	高
既知脆弱イメージ展開	高	高	高	高
逃避試行（mount, setns）	なし	なし	高	高
Secret 収集と外部送信	なし	なし	中〜高	高
異常 DNS/egress	なし	なし	中	高

表5は、検知指標の比較例である。数値は導入モデル間の傾向を示すための代表値であり、組織の負荷やルール成熟度によって変動する。

構成	Precision	Recall	F1	平均 $T_d$	平均 $T_c$
静的スキャンのみ	0.91	0.42	0.57	18分	なし
Admission + 署名	0.94	0.68	0.79	4分	12分
Runtime + eBPF	0.88	0.86	0.87	35秒	3分
四面防御統合	0.93	0.92	0.92	22秒	2分

表6は、運用上のオーバーヘッドをまとめたものである。

機構	CPU 増分	メモリ増分	アラート件数/日	導入難度
Falco	中	低〜中	中〜高	低〜中
Tetragon	低〜中	中	中	中
Gatekeeper	低	低	低〜中	中
Kyverno	低	低	低〜中	低〜中
Cilium	低〜中	中	低〜中	中〜高
SBOM/署名 CI	低	低	低	中

この評価から、静的スキャンは初期品質向上には有効だが、実行時の逃避や資格情報の動的悪用には不十分であることが分かる。Admission は「危険な形の Pod」をかなりの割合で遮断するが、実行時の環境変化までは制御できない。Runtime は侵入後の挙動を捉えられるが、誤検知管理が必要である。したがって、実務的には四面防御が最もバランスが良い。なお、評価においては、ポッド削除による業務影響も考慮し、重要サービスでは自動隔離と限定運転への切替えを優先する。

7. Case Study

対象事例として、仮想的な決済基盤「MercuryPay」の Kubernetes クラスタを想定する。MercuryPay は、複数のマイクロサービス、外部決済ゲートウェイ、バッチ処理、監査ログ集約、そして ML ベースの不正検知サービスから構成されている。導入前は、開発速度を優先するあまり、namespace ごとの権限分離が甘く、CI から直接レジストリへ push されたイメージは署名されていなかった。また、ある監視コンポーネントが hostNetwork と hostPath を使い、さらに一部のジョブが ServiceAccount トークンを長期間保持していた。

侵害は、まず公開 API の脆弱な依存関係に起点を持つ。攻撃者は、正規の更新プロセスに見える pull request へ依存ライブラリ差し替えを混入し、ビルド成果物にバックドアを埋め込んだ。署名必須でなかったため、当該イメージは本番へ展開された。次に、バックドアはクラスタ内のメタデータと Secret を列挙し、過剰権限の ServiceAccount を発見した。さらに、監視コンポーネントの特権設定を踏み台にしてノード上で追加権限を取得し、外向き通信で C2 と接続した。

導入後の防御では、まず Build stage に cosign verify と trivy を追加し、未署名イメージを拒否した。Admission では、restricted プロファイルを既定化し、hostPath と privileged を明示的に禁止した。Runtime では、Falco によりシェル起動、kubectl exec、/proc 参照、外向き curl を検知し、Tetragon により関連プロセス系譜を可視化した。結果として、同様の試行は初期段階で遮断され、封じ込め時間は平均で数十分から数分へ短縮された。特に、例外運用の棚卸しと ServiceAccount の分離が効果的であった。

この事例の教訓は、コンテナ侵害の本質が「単一の穴」ではなく「複数の小さな緩みの連鎖」にあることである。署名がなければ供給網汚染が通り、権限が過剰なら逃避の足場ができ、egress が開いていれば持続化が成立する。したがって、単独の高性能ツールよりも、運用の整合性を保つ複合防御の方がはるかに重要である。

8. Discussion

コンテナ・セキュリティの最大の誤解は、「コンテナは軽量だから安全でもある」という期待である。実際には、軽量であることは攻撃者にとっても都合がよい。起動が速いということは、悪性 Pod を大量に作成して探索することも、短時間で痕跡を消すことも容易だという意味である。また、イメージの再利用は効率的だが、同じ脆弱性を多数の環境に横展開する。コンテナは安全性を自動的に提供しない。安全性は、強制ポリシー、監査、継続的検証、そして運用文化の積み重ねによってのみ成立する。

2026年の現実では、AI を利用した攻撃が防御をさらに難しくしている。攻撃者は、クラウド設定の推測、フィッシング文面の最適化、権限昇格の試行錯誤、ポリシーの穴探しを高速化できる。防御側も同様に、異常検知ルールの生成、ログ相関、ポリシー案の評価、脅威モデリングの補助に AI を使うが、誤推論や過学習に注意が必要である。特に、LLM ベースの運用支援は、説明性の低い提案をそのまま採用すると危険であるため、最終判断は常に人間のレビューと変更管理に従うべきである。

ゼロトラストは、コンテナ環境で特に重要になった。従来の「クラスタ内部は信頼できる」という前提はすでに成立しない。Pod は一時的で、ノードは共有され、CI/CD は高速で、Secret は分散し、サードパーティサービスが多い。したがって、信頼境界はネットワーク・セグメントではなく、アイデンティティ、証明書、ポリシー、短命トークンに置く必要がある。mTLS と workload identity はこの方向性に合致するが、万能ではない。証明書の発行・失効・ローテーションが破綻すると、ゼロトラストは単なる用語になる。

また、コンテナ・セキュリティはクラウド・ベンダーの管理機能と密接に結びついている。CNAPP は可視化と統合管理に便利だが、各ベンダーの検知ロジックやコンテキスト理解は異なる。したがって、単一ベンダーにロックインされた検知基盤だけに依存するのは危険である。理想は、Kubernetes ネイティブのポリシー、eBPF ベースの実行時テレメトリ、レジストリ署名検証、クラウド IAM の最小化を相互補完させることだ。これにより、ある製品の見逃しを別の層で補える。

一方で、過剰なセキュリティは開発速度を損ねる。現場では、検証を厳しくしすぎると回避策が増え、結果としてリスクが上がることがある。したがって、セキュリティ制御は「止める」だけでなく、「安全に進める」ための支援として設計すべきである。たとえば、拒否理由の明確化、自動修正提案、例外の有効期限、段階的導入、開発環境との差異の最小化が重要である。セキュリティは開発の敵ではなく、変更の品質保証として機能しなければならない。

9. Conclusion and Future Work

本稿は、2026年時点のコンテナ・セキュリティを、供給網、投入時制御、実行時監視、アイデンティティ、ネットワークの四面防御として体系化した。主要な結論は、コンテナ侵害の多くが単一の脆弱性ではなく、誤設定、権限過多、秘密情報、サプライチェーン、ランタイム欠陥の連鎖で成立するという点にある。したがって、最も有効な防御は、署名と SBOM による由来保証、Admission Policy による形状制約、eBPF/LSM による実行時監視、そしてゼロトラスト型の通信・認証制御を統合することである。

今後の研究課題は三つある。第一に、eBPF テレメトリと CNAPP、SIEM、SOAR を結合した、より高精度な自動封じ込めである。第二に、AI を利用した攻撃と防御の双方に対する評価基準を整備し、ルール生成や異常検知の信頼性を定量化することである。第三に、ポスト量子暗号への移行を見据え、コンテナ・ワークロードでの証明書更新、鍵ローテーション、相互認証の運用負荷を低減することである。2026年以降、コンテナ・セキュリティは単なる実装技術ではなく、組織の運用成熟度そのものを映す指標になっていくだろう。

10. References

[1] BURNS, Brendan; BEDA, Joe; HIGHTOWER, Kelsey. Kubernetes: Up and Running. 3. ed. Sebastopol: O’Reilly Media, 2022. Disponível em: https://www.oreilly.com/library/view/kubernetes-up-and/9781098110192/
[2] BIEGLER, Christoph et al. Understanding and Hardening Container Security. 2021. Disponível em: https://www.usenix.org/conference/usenixsecurity21/presentation/biegler
[3] XU, Wei et al. Security Analysis of Container Technologies. 2020. Disponível em: https://arxiv.org/abs/2001.08219
[4] The Linux Kernel Documentation. Namespaces. 2026. Disponível em: https://www.kernel.org/doc/html/latest/admin-guide/namespaces/index.html
[5] The Linux Kernel Documentation. cgroup v2. 2026. Disponível em: https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html
[6] Kubernetes Documentation. Pod Security Admission. 2026. Disponível em: https://kubernetes.io/docs/concepts/security/pod-security-admission/
[7] Kubernetes Documentation. Security Context. 2026. Disponível em: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
[8] Kubernetes Documentation. RBAC Authorization. 2026. Disponível em: https://kubernetes.io/docs/reference/access-authn-authz/rbac/
[9] Kubernetes Documentation. Network Policies. 2026. Disponível em: https://kubernetes.io/docs/concepts/services-networking/network-policies/
[10] SIGSTORE Project. Cosign. 2026. Disponível em: https://docs.sigstore.dev/cosign/overview/
[11] SIGSTORE Project. Rekor. 2026. Disponível em: https://docs.sigstore.dev/rekor/overview/
[12] Anchore. Syft. 2026. Disponível em: https://github.com/anchore/syft
[13] Anchore. Grype. 2026. Disponível em: https://github.com/anchore/grype
[14] Aqua Security. Trivy. 2026. Disponível em: https://github.com/aquasecurity/trivy
[15] The Open Policy Agent. Gatekeeper. 2026. Disponível em: https://open-policy-agent.github.io/gatekeeper/website/
[16] Kyverno Project. Kyverno Documentation. 2026. Disponível em: https://kyverno.io/docs/
[17] Falco Security. Falco Documentation. 2026. Disponível em: https://falco.org/docs/
[18] Cilium Project. Cilium Documentation. 2026. Disponível em: https://docs.cilium.io/en/stable/
[19] Kubernetes SIG Security. Kubernetes Hardening Guidance. 2026. Disponível em: https://github.com/kubernetes/community/blob/master/sig-security/pod-security-standards.md
[20] CNCF. Software Supply Chain Security Best Practices. 2026. Disponível em: https://www.cncf.io/blog/
[21] SLSA Framework. Supply-chain Levels for Software Artifacts. 2026. Disponível em: https://slsa.dev/
[22] in-toto. in-toto Framework. 2026. Disponível em: https://in-toto.io/
[23] NIST. Zero Trust Architecture. 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-207/final
[24] NIST. Secure Software Development Framework (SSDF). 2022. Disponível em: https://csrc.nist.gov/Projects/ssdf
[25] MITRE. ATT&CK for Containers. 2026. Disponível em: https://attack.mitre.org/matrices/enterprise/containers/
[26] MITRE. ATT&CK for Kubernetes. 2026. Disponível em: https://attack.mitre.org/matrices/enterprise/kubernetes/
[27] CVE Program. CVE-2019-5736. 2019. Disponível em: https://www.cve.org/CVERecord?id=CVE-2019-5736
[28] CVE Program. CVE-2022-0847. 2022. Disponível em: https://www.cve.org/CVERecord?id=CVE-2022-0847
[29] CVE Program. CVE-2022-0492. 2022. Disponível em: https://www.cve.org/CVERecord?id=CVE-2022-0492
[30] CVE Program. CVE-2024-21626. 2024. Disponível em: https://www.cve.org/CVERecord?id=CVE-2024-21626