攻撃者は「デプロイ後」を狙いに来た —— 2026年、炎上するKubernetesと私たちの防御戦略

2026年、「コンテナはコンテナではなくなった」

長く信じられてきた前提がある。「アプリが乗っ取られても、コンテナという檻がある。外には出られない」。軽量な隔離の象徴であり、Kubernetes安全神話の土台だった。

2026年は、その前提が音を立てて崩れた年だった。しかも厄介なことに、今年のインシデントは「ポートを開けすぎた」「パスワードが弱かった」といった初歩的ミスの延長上にない。自分のコードは完璧で、設定も正しく、デプロイも成功している——その"その後"で、やられている。

この記事では今年を代表する3つの事件を整理し、共通する構造を読み解いた上で、私たちがKuboでどう防御の形にしようとしているかまで書く。

事例1: Copy Fail (CVE-2026-31431) —— 「暗号化API」からの脱出

4月下旬に公開された、Linuxカーネルの AF_ALG（algif_aead）——ユーザー空間からカーネルの暗号化機能にアクセスする、あの旧いソケットAPI——の論理バグ。CVSSは7.8（High）。ローカルでのコード実行が前提だから、と最初は皆タカをくくっていた。

ところが実際は違った。

• コンテナの中から、特別な権限もなしに通常のシステムコールを叩くだけで、ノード上のroot特権が取れるPoCが即座に公開された（"trivially exploitable"）
• Pod Security Standardsのrestrictedや、デフォルトのseccompプロファイル（RuntimeDefault）は、この AF_ALG ソケットの生成を塞がないことが複数の検証で確認された
• Talos LinuxのようにそもそもこのAPIを削っているディストリビューションはほぼ無傷で、逆に「標準的」なカーネルを持つ環境が軒並み晒された

重要なのは「Kubernetesの脆弱性ではない」という点ではない。コンテナの壁はカーネルであるということだ。同じカーネルを共有する限り、壁の中に立てこもっても、カーネル自体に穴が開いていれば檻は檻でなくなる。

事例2: Ubuntu AF_UNIX脆弱性 (CVE-2026-80521) —— 「パッチが間に合わない」世界

夏に判明した、AF_UNIXソケットのガベージコレクションにおけるuse-after-free（解放後メモリ再利用）の競合バグ。こちらもコンテナ内からの「ありふれた」システムコールの連鎖で、namespace分離・cgroup制限・seccompフィルタをすべて素通りしてホストのrootに至る。

そしてCopy Failよりたちが悪いのが、これだ。

• 影響を受けるのは Ubuntu 22.04 / 24.04 / 26.04 LTS——世界中のサーバーとビルド環境の相当数が該当する
• 記事執筆時点（2026年10月）で修正パッチは未提供、タイムラインも未公開

「脆弱性が公表されたら、パッチを当てて終わり」というセキュリティの常識は、パッチが存在しなければ機能しない。公表から適用まで数日、ディストリビューションが修正を出すまで数週間——その"空白の1か月"をどう生き延びるかが、今年の運用者を真正面から問い詰めた。

事例3: LiteLLMサプライチェーン攻撃 —— 侵入者はパイプラインの中にいた

3月、脅威グループ "TeamPCP" がやったことは単一だ。セキュリティスキャナTrivyの自動化トークンを盗んだ。それだけ。

ここからが地獄のドミノだった。

• 盗んだトークンでTrivy本体のリリースタグに約20日間にわたり悪性コードをforce-push。つまり「正規の最新版」を標的に汚染した
• LiteLLMのCIがその汚染されたTrivyを実行した結果、悪性バージョン1.82.7 / 1.82.8がPyPIに公開された（生存時間はわずか約40分。ただしCIの自動更新はこの40分を容赦なく捕まえた）
• パッケージ内の .pth ファイルがPythonインタープリタの起動時にペイロードを実行する。importすら不要、インストールしただけで発火する設計で、--ignore-scripts も無効化した
• 盗まれたのはSSH鍵、AWS/GCP/Azureのクレデンシャル、Kubernetesトークン、.env、LLM APIキー、さらにはプロセスメモリから漁ったCI/CDシークレット

追跡された被害は2,500社以上、434,000本以上のCI/CDパイプライン。FBIも7月に「パッケージを削除した後も、盗まれたクレデンシャルは生き続ける」と警告を出している。防御ツールが攻撃の運び屋になった年。これは2026年最大の教訓だ。

3つに共通すること: 攻撃は「デプロイ後」に移動した

3事件を並べると、輪郭がくっきり浮かぶ。

• 共通点1: 被害者のミスでは始まらない。 コードの脆弱性でも、設定ミスでも、フィッシングでもない。カーネル、実行環境、ツール、依存関係——「信頼していた内側」そのものが穴だ
• 共通点2: 境界が一段ではなく三段抜ける。 コンテナ→ノード→クラスター→クレデンシャル経由でクラウド・CI/CDへ。抜けた「その先」が前提化している
• 共通点3: 防御の主戦場が"検知と回復の速さ"に移った。 侵入を100%止められない世界で、勝負するのは「いつ気づき、いつ隔離し、いつローテートするか」

古い安全の語り方——「警戒しよう、注意しよう」——は、もはや前提から壊れている。注意が防御になるのは、人間が常に正しい判断をできる場合だけだ。前提が崩れたのだから、気合ではなく構造で守るしかない。

私たちが実際にやっていること: 構造防御チェックリスト

理想論ではなく、今年の事件から逆算した等式で書く。

カーネル・ホスト層

• ノードOSの更新を「四半期」ではなく「週・日」の間隔で回せる運用にする。更新できない運用こそが最大の脆弱性
• seccompプロファイルで AF_ALG に加えリスクの高いソケット生成を明示的に拒否する（デフォルトプロファイルは守ってくれない）
• 特権ワークロード・マルチテナントな実行環境にはgVisorやKata ContainersなどマイクロVM分離を検討する
• privileged pod、hostPath、hostNetworkはPolicy（Kyverno / OPA / PSA）で構造的に禁止し、例外には責任者と有効期限を付ける

パイプライン層

• 依存もGitHub Actionsもバージョン名ではなくハッシュでピン留めする（タグは書き換えられる。今年証明された）
• すべてのトークンを棚卸しする。「誰も所有者ではないトークン」を即座に無効化する。LiteLLM事件は自動化トークン1本から始まった
• 静的キーをやめ、OIDC等によるworkload identityと短期クレデンシャルへ移行する
• ビルドキャッシュ・ランナーイメージも「汚染されうる資産」として定期検証する

検知・対応層

• クラスター内のSecret / ConfigMapを定時にスキャンし、漏れをその日に知る（私たちは実際にやっている。下記参照）
• デプロイログとシェルアクセス履歴を必ず残す。「誰がいつ何を実行した」が一覧できない環境は、事故後に何も復元できない
• クレデンシャルは「いずれ漏れる」前提でローテーション設計する。漏洩から数時間で無効化できないシークレットは、存在自体が時限爆弾

Kuboで、どう考えているか

Kuboは「自分のハードウェアで、自分のクラスタを回す」ためのプラットフォームだ。Proxmox上のk3sクラスタを数分で立て、Gitリポジトリからデプロイし、ログも監視もダッシュボードも、自分の手元にある。なぜ2026年にこの話をするか——今年の事件のほぼすべてに、共通の問いがある。「自分のインフラを、自分の都合のよいタイミングで更新し、全部見えるようにできるか」だ。

Kuboの設計と、今年の教訓の対応関係を正直に書く。

• 単一テナント・自分ハードウェア: 見知らぬ隣人とカーネルを共有しない。ノードの所有権が明確なら、影響範囲の切り分けが「一日かかる」ではなく「数分で終わる」になる。ただし誤解なきよう——カーネルバグは自分の手元でも消えない。消えるのは「誰と何を共有しているか分からない」という最悪の条件だけだ
• 素早いノードOS更新とロールバック: クラスタのライフサイクル操作が直感的でないから、本番の更新に腰が重い。Kuboは「更新の速さ」をそのまま防御速度にできる構成にしている。CVE-2026-80521のようにパッチが1か月遅れる世界では、パッチが出てから適用完了までの時間を詰めることが数少ない対策になる
• Git起点のデプロイとログの全残し: 出所不明のビルドが本番に立つ余地をなくす。ハッシュピン留めやシークレット注入も、マニフェストの手編集ではなくアプリ定義のレベルで統一できる形にしていきたい
• Webターミナルとアクセス権管理: Podへのシェルアクセスを、SSH鍵のばら撒きではなく権限付きの監査可能な経路に寄せる。「盗まれる鍵の在庫」自体を減らす発想だ
• ダッシュボードでの可視化: QuestDBベースのデプロイログ、API利用状況、エラーログ。「様子がおかしい」を感覚ではなくデータで検知できるようにする。今年の事件で最も高価だったのは、気づくまでの時間だ

そしてこれは製品の話ではなく実運用の話だが、私たちは自前のk3sクラスタに30分間隔のシークレットスキャンCronJobを常駐させ、検知をその場で通報させている。「漏れているかも」と「漏れていると今日わかった」では、被害額が桁違いになることを自分のインフラで知ったからだ。

誠実に言っておくが、Kuboはウイルス対策ソフトではない。カーネルが弱ならカーネルを更新しろ、人が弱なら構造で枷めよ。それでも、「誰が、どこで、何を実行しているか」が一覧できて、自分のタイミングで全部を更新・隔離・巻き戻せること。2026年が教えてくれた損害限定の第一歩は、ここだと思う。

まとめ

• 2026年、コンテナ分離・実行環境・CI/CDが同時に崩された。攻撃者はデプロイの"後"に移動した
• 警戒や注意ではなく構造で守る: ソケット単位の分離、ハッシュピン留め、短期クレデンシャル、そして全経路の可視化
• 自分のインフラを自分のタイミングで更新・巻き戻せること。地味だが、それが最強の防御になる

Kuboは現在アルファ版を無料で公開している。「全部自分の手で回す」という問いに、一緒に答えてみてほしい。