OWASP Kubernetes Top 10 (2025) ハンズオン

キャプチャ・ザ・フラグ（CTF） 形式で、OWASP Kubernetes Top 10 — 2025 に基づいています。あなたは架空のeコマース企業 NimbusMart のレッドチームに採用されました。同社のクラスターはセキュリティよりも速く成長しました。10個のチャレンジ（OWASPリスクごとに1つ、ボーナスあり）— 各脆弱性を悪用し、フラグをキャプチャし、修正を適用してチェッカーで証明します。

世界観の聖書（企業、サービス、名前空間、フラグの仕組み）は labs/NIMBUSMART.md にあります。

すべてはローカルの kind で動作します。本番クラスターに対して脆弱なマニフェストを決して実行しないでください。

作成者: @hac01

対象範囲

これはスライド資料ではありません — 実際に動作し、意図的に脆弱性を持たせたKubernetesクラスターと、それを攻撃、修正、修正の確認を行うためのツールです。11のチャレンジを通じて、以下のテーマについてハンズオンで学べます：

• コンテナとノードのセキュリティ — 特権ポッド、hostPathマウント、ノードからの脱出 (K01)。
• RBACと認可 — ワイルドカード ClusterRole、過剰な権限を持つServiceAccount、そして1つの盗まれたトークンですべてのシークレットに到達する方法 (K02, K09)。
• シークレット管理 — env/ConfigMapにハードコードされたAPIキーとより安全な代替手段 (K03)。
• アドミッション制御とポリシー — クラスター全体でルールが強制されていないときにすり抜けるもの、そしてPod Security Admissionやポリシーエンジンがどのように阻止するか (K04)。
• ネットワークセグメンテーション — フラットなポッドネットワーク vs. NetworkPolicy によるロックダウン (K05)。
• 露出したコンポーネント — NodePort経由で公開された内部ダッシュボードやAPI (K06)。
• クラスターコンポーネントの衛生 — デフォルトトークン、不足しているクォータ、古い/脆弱なバージョン (K07)。
• クラスターからクラウドへの水平移動 — ポッドがノードメタデータ(IMDS)エンドポイントにアクセスしてクラウド認証情報を盗む (K08)。
• 認証 — 匿名APIアクセスと過剰なデフォルトトークンのマウント (K09)。
• ログと監視 — サイレントデータ流出の検出（または検出の失敗）、および監査証跡が重要な理由 (K10)。
• サプライチェーン — 信頼できない、可変的な :latest イメージが本番に出荷される (ボーナス)。

各チャレンジでは以下を提供します：

• ミッションブリーフィング — NimbusMartのシナリオ、足がかり、目標。
• キャプチャするフラグ — エクスプロイトを実行することでのみ到達可能（ノード上、別の名前空間、ネットワーク経由）。Webアプリで送信、スコアボードが進捗とポイントを追跡（ブラウザのlocalStorage）。
• 段階的なヒントとネタバレ解説 — 最初はヒント、必要なときに完全な解決策。
• 深掘り概要 — 脆弱性の内容、攻撃者の悪用方法、影響、根本原因。
• 防御ガイド — 具体的なパッチとベストプラクティスのチェックリスト。
• 自動チェッカー — クラスターをスキャンして、リスクごとに修正が有効かどうかを確認するGoバイナリ。

前提条件

開始前にこれらをインストールしてください。セットアップスクリプトは最初の4つをチェックし、不足している場合は明確なメッセージですぐに失敗します。

brew コマンドはmacOS用です。Linuxではパッケージマネージャーまたはリンク先の公式インストール手順を使用してください。

クイックスタート（推奨）— すべてを1つのクラスター内に

Webアプリ、ブラウザ内ターミナル、チェッカーはすべて kindクラスター内 で実行できます。1つのコマンドですべてを起動し、URLを表示します：

./setup.sh          # or: make up
#   - creates the kind cluster, builds and loads images, deploys, waits for ready
#   - Web app:  http://localhost:30090
#   - Terminal: the 'Terminal' button in the web app

./setup.sh は適切なポートマッピングでクラスターを（再）作成し、2つのイメージ（nimbusmart-ctf-web、nimbusmart-ctf-terminal）をビルドし、kindにロードして、deploy/ を適用します。初回実行ではベースイメージをプルするため約1〜2分かかります。

./setup.sh            # fresh cluster + full platform (deletes any old 'owasp-labs' cluster)
./setup.sh --keep     # reuse an existing 'owasp-labs' cluster if present

その後、http://localhost:30090 を開き、チャレンジを選び、ブラウザのTerminalボタンを使用してクラスターを操作します。

ターミナルポッドは cluster-admin ServiceAccountとして実行されるため、ブラウザのターミナルがこのクラスターを直接操作します — その場で kubectl apply -f labs/... や owasp-k8s-checker --check kNN を実行できます。

警告: ブラウザ内ターミナルは実質的にWebSocket経由のcluster-adminです。これは localhost 上のローカルで使い捨て可能なkindクラスターにバインドされているため安全です。ポート 30080/30090/30091 を信頼できないネットワークに公開しないでください。

クリーンアップ

kind delete cluster --name owasp-labs      # or: make cluster-down

リポジトリ構成

.
├── setup.sh         ワンコマンドブートストラップ（クラスター、イメージ、デプロイ）
├── Makefile         便利なターゲット — `make help` で一覧表示
├── web/             Next.js + Reactアプリ（白/紫テーマ）— UI
├── labs/            リスクごとの実際のK8sマニフェスト（vulnerable.yaml + fixed.yaml + README）
│   ├── NIMBUSMART.md        世界観の聖書：企業、名前空間、フラグの仕組み
│   └── kind-cluster.yaml    共有ローカルクラスター設定（ポートマッピング）
├── deploy/          クラスター内プラットフォームマニフェスト（Web、ターミナル、RBAC）+ build.sh
├── terminal-server/ ブラウザ内ターミナルのWebSocketバックエンド
└── checker/         Top 10に対するクラスターを検証するGoバイナリ

便利な make ターゲット（make help ですべて表示）：

OWASP Kubernetes Top 10 — 2025

各チャレンジはNimbusMartのクラスターにおける実際の脆弱性です — ターゲットを選び、それを悪用し、フラグをキャプチャし、修正してチェッカーで修正を証明します。

2022年からの変更点： 認可（旧RBAC）の拡大、シークレット、ネットワーク、認証、ログの順序変更。過度に露出したコンポーネント（K06）とクラスターからクラウドへの水平移動（K08）を追加。誤設定および古いコンポーネントをK07に統合。サプライチェーンはボーナスチャレンジに移動。完全なチャレンジ-サービス-脆弱性マップ、難易度、ポイント（10チャレンジで2000点、ボーナス+300点）については labs/NIMBUSMART.md を参照。

手動/開発ワークフロー（クラスター内プラットフォームなし）

UIをローカルで実行し、自分のシェルからラボを操作したいですか？手動で各部分を組み立てられます。

1. Webアプリをローカルで実行

cd web
npm install
npm run dev
# open http://localhost:3000       (or: make web)

ターミナルバックエンドは ~/.kube/config を使用して別途 :30091 で実行されます：

make terminal-local

2. ラボクラスターを作成

kind create cluster --config labs/kind-cluster.yaml    # or: make cluster
kubectl config use-context kind-owasp-labs

3. チャレンジをプレイ

各チャレンジには独自のREADMEがありますが、パターンは同じです：

# some challenges seed a target first (a node file, an ops secret, ...)
kubectl apply -f labs/k01-insecure-workload/setup.yaml       # only if present

# deploy the vulnerable resource and exploit it to capture the flag
kubectl apply -f labs/k01-insecure-workload/vulnerable.yaml
# ...follow the mission briefing / hints in the web app, grab FLAG{...}, submit it...

# apply the hardened version and confirm the flag path is closed
kubectl delete -f labs/k01-insecure-workload/vulnerable.yaml
kubectl apply  -f labs/k01-insecure-workload/fixed.yaml

チャレンジ間のリセットは make clean-labs で行います。

4. チェッカーで検証

cd checker
go run . --list            # show all checks
go run . --check k01       # run a single check
go run . --all             # scan the whole cluster
go run . --all --json      # machine-readable (for CI)
go run . --all -n apps     # scope to a namespace

チェッカーはチェックが失敗すると非ゼロで終了するため、CIのゲートとして使用できます。

スタンドアロンバイナリのビルド：

cd checker
go build -o owasp-k8s-checker .    # or: make checker
./owasp-k8s-checker --all

チェッカーとラボの対応

各 checker/checks/kNN.go は対応するラボが教える同じコントロールを検証します。fixed.yaml をデプロイし、go run . --check kNN を実行すると PASS と表示されるはずです。vulnerable.yaml をデプロイすると、同じチェックが具体的な結果を報告します。

安全性： 脆弱なマニフェストは意図的に悪用可能です。ローカルで使い捨て可能な kind/minikube クラスターのみ使用してください。終了後は削除：kind delete cluster --name owasp-labs。