前言：為什麼 Kubernetes 安全需要一套攻擊框架？

2025 年，全球超過 60% 的生產環境運行在容器化平台上，Kubernetes 已經是事實上的標準。然而大部分的 K8s 安全指南停留在「強化清單」層次——告訴你該做什麼，卻沒解釋攻擊者怎麼打進來。

如果你不了解攻擊者的思維路徑，防禦就只是打勾而已。

這就是為什麼我們需要 MITRE ATT&CK。

本篇是全系列的基石——上半場帶你走一遍 ATT&CK Containers Matrix 的 10 個戰術 × 28 個技術，下半場直接動手把 KOAD 靶場跑起來。讀完這篇，你會有兩樣東西：一張攻擊全景圖，和一座可以親手操作的靶場。

學習目標

完成本日實作後，你將能夠：

• 理解 ATT&CK Containers Matrix 的 10 個戰術 × 28 個技術
• 在本地環境部署完整的 KOAD 攻防靶場（35 場景 + 防禦堆疊）
• 驗證 Falco、Kyverno、NetworkPolicy 是否正常運作
• 存取靶場中的 Web 服務（SSRF Webapp、Jupyter Notebook）

先備知識：容器與 Kubernetes 是什麼？

如果你已經熟悉 Docker 和 K8s 架構，可以直接跳到下一節「什麼是 MITRE ATT&CK」。

什麼是容器？

傳統部署中，應用程式直接跑在作業系統上，共用函式庫。一個更新壞了，其他應用跟著掛。

容器把應用程式和它的所有依賴（程式碼、函式庫、設定）打包成獨立的單元——不管放到哪台機器上都能跑，互不干擾。

最後一點正是本系列的核心——容器共用宿主機核心，隔離配置不當就能「逃逸」到宿主機。Day 8–13 會拆解六種逃逸手法。

Docker 是最主流的容器引擎。核心概念只有三個：

• 映像（Image）：應用的唯讀模板（像光碟片）
• 容器（Container）：映像跑起來的實體（光碟裝好跑起來的程式）
• Dockerfile：描述怎麼做出映像的腳本（安裝說明書）

動手試一下 Docker

如果你已經裝好 Docker，花兩分鐘跑一下：

# 1. 跑第一個容器（會自動下載映像）
docker run hello-world

# 2. 進入一個 Ubuntu 容器（-it = 互動模式）
docker run -it ubuntu bash
# 在容器內試試：
ls /        # 看到的是容器自己的檔案系統
cat /etc/os-release   # Ubuntu，不是你的宿主機
exit        # 離開容器

# 3. 查看目前的容器和映像
docker ps -a    # 列出所有容器（含已停止的）
docker images   # 列出本機的映像

如果還沒裝 Docker，沒關係——後面的 KOAD 靶場用 Minikube，會自動處理容器環境。這裡只是讓你感受一下「容器是什麼」。

什麼是 Kubernetes？

一個容器很簡單，但生產環境有幾百個容器——誰來決定容器跑在哪台機器、掛了自動重啟、流量怎麼分配？

Kubernetes（K8s） 就是容器的「管理平台」。它負責自動調度、自動修復、負載均衡、滾動更新。

K8s 架構分兩層：

K8s 核心概念速查

什麼是 MITRE ATT&CK？

ATT&CK（Adversarial Tactics, Techniques, and Common Knowledge）是由 MITRE 維護的攻擊知識庫。它把真實世界中觀察到的攻擊手法，按照**戰術（Tactics）和技術（Techniques）**兩個維度進行分類：

• 戰術（Tactic）：攻擊者「想要達成什麼」——初始存取、執行、持久化、提權……
• 技術（Technique）：攻擊者「如何達成」——SSRF、容器逃逸、竊取 Token……

ATT&CK 有多個矩陣（Enterprise、Mobile、ICS），而 2021 年正式加入的 Containers Matrix 專門描述容器與編排平台的攻擊面。

ATT&CK 對防禦者的價值

MITRE ATT&CK Containers Matrix：10 個戰術 × 28 個技術

Containers Matrix 定義了攻擊者從入侵容器化環境到造成影響的完整殺傷鏈。以下逐一拆解每個戰術和對應技術。

TA0001 Initial Access — 初始存取

攻擊者如何取得在容器環境中的第一個立足點。

KOAD 場景： S01 SSRF 漏洞 Web App、S02 暴露的 kubelet、S03 洩漏的 kubeconfig

現實案例： 2022 年某電商因 SSRF 漏洞被打穿 Metadata API，攻擊者取得雲端 IAM 憑證後橫向移動至生產資料庫。這正是 T1190 的經典路線。

攻擊者視角： 初始存取是整條 Kill Chain 最關鍵的一步——進不去就什麼都做不了。在 K8s 環境中，最常見的入口不是什麼零日漏洞，而是暴露的管理介面和洩漏的 kubeconfig。Shodan 上隨時能找到數千個暴露的 kubelet 連接埠。

TA0002 Execution — 執行

攻擊者取得立足點後，如何在容器環境中執行指令。

KOAD 場景： S04 Jupyter Web Shell、S05 kubectl 控制叢集、S06 部署特權 Pod、S07 CronJob 持久化、S08 釣魚 Pod

關鍵觀念： 在 K8s 中，「執行」不只是跑一條指令。部署一個 Pod 本身就是一種執行——而且一旦 Pod 啟動，攻擊者就有了持續運行的工作負載。kubectl apply -f evil-pod.yaml 這一條指令就足以在叢集中開啟一個永久的立足點。

TA0003 Persistence — 持久化

攻擊者如何確保失去初始存取後仍能回來。

KOAD 場景： S09 RBAC 竄改、S10 後門 SA、S11 Sidecar 注入、S12 映像植入

關鍵觀念： K8s 的持久化手法比傳統 Linux 更豐富。攻擊者不需要寫 crontab 或改 systemd，只要在 RBAC 加一條 ClusterRoleBinding，就擁有永久的叢集管理員權限。而且這條 Binding 藏在幾百個 RBAC 物件中，不主動審計根本不會被發現。

TA0004 Privilege Escalation — 權限提升

攻擊者如何從容器內的低權限提升到節點或叢集層級。

KOAD 場景： S13–S18 容器逃逸六式、S19 核心 CVE 提權

容器逃逸六式——Day 8–11 的核心內容：

這六種逃逸手法將在 Day 8–11 逐一拆解，每個場景都可以在 KOAD 靶場中實際操作。

TA0005 Stealth — 隱匿

攻擊者如何隱藏自己的行動。

KOAD 場景： S20 宿主機建映像、S21 痕跡清除、S22 偽裝系統元件

為什麼隱匿重要： 真正的攻擊者不會像 KOAD 測試那樣一次觸發 174 條 Falco 告警。他們會用合法帳號、合法映像、合法操作來掩護自己。偽裝成 kube-proxy 的 Pod 在 kubectl get pods 裡看起來完全正常——除非你仔細比對映像 hash。

TA0112 Defense Impairment — 防禦破壞

攻擊者如何癱瘓你的安全監控。

KOAD 場景： S23 停用安全工具

關鍵觀念： 在 K8s 中，安全工具本身就是叢集內的工作負載。攻擊者如果有 cluster-admin 權限，一條 kubectl delete ds falco -n falco 就能讓你的 Runtime 偵測全面失效。這是為什麼 RBAC 最小權限如此重要——保護安全工具的 Namespace 應該有獨立的、限制極嚴格的 RBAC。

TA0006 Credential Access — 憑證存取

攻擊者如何竊取叢集中的機密資訊。

KOAD 場景： S24 暴力破解、S25 竊取 Token、S26 明文憑證

你可能不知道的事實： K8s Secret 預設只是 base64 編碼，不是加密。kubectl get secret db-password -o jsonpath='{.data.password}' | base64 -d 就能看到明文。如果 etcd 沒有啟用靜態加密（encryption at rest），任何能讀 etcd 的人都能拿到所有 Secret。

TA0007 Discovery — 探索

攻擊者如何了解叢集的全貌。

KOAD 場景： S27 資源列舉、S28 網路掃描、S29 RBAC 探測

TA0008 Lateral Movement — 橫向移動

攻擊者如何從一個 Namespace 移動到另一個。

KOAD 場景： S30 跨 Namespace Token 橫向移動

關鍵觀念： K8s 的 Namespace 不是安全邊界。如果 RBAC 配置不當，攻擊者拿到一個 cluster-admin 的 SA Token 就能存取所有 Namespace 的資源。真正的隔離需要 NetworkPolicy + RBAC + 獨立叢集三管齊下。

TA0040 Impact — 影響

攻擊者最終造成的破壞。

KOAD 場景： S31 資料破壞、S32 Resource Bomb、S33 阻止恢復、S34 網路 DoS、S35 挖礦劫持

挖礦是最常見的 K8s 攻擊目標： 根據 Sysdig 2025 Container Security Report，超過 65% 的容器入侵事件最終目的是挖礦。因為 K8s 叢集通常有大量 CPU 和自動擴展能力——對攻擊者來說，這就是免費的算力。

微軟 Kubernetes 威脅矩陣 vs ATT&CK

微軟在 2020 年發布了 Kubernetes 威脅矩陣，從另一個維度切入：

微軟矩陣的三大攻擊面：

1. 叢集（Cluster）：API Server 未授權、RBAC 錯誤配置、etcd 暴露
2. 容器（Container）：映像漏洞、特權容器、容器逃逸
3. 供應鏈（Supply Chain）：CI/CD 投毒、Registry 滲透、映像 tag 劫持

兩者高度互補——ATT&CK 適合設計偵測規則，微軟矩陣適合盤點攻擊面。KOAD 以 ATT&CK 為主架構，同時覆蓋微軟矩陣的所有攻擊面。

OWASP Kubernetes Top 10（2025）

OWASP 在 2025 年更新的 K8s Top 10 與 ATT&CK 技術的對應：

CKS 六大領域 × ATT&CK 對照

如果你正在準備 CKS（Certified Kubernetes Security Specialist）認證，ATT&CK 矩陣可以幫助你理解每個考試領域對應的攻擊場景：

宣布 KOAD：第一個 100% 覆蓋 ATT&CK Containers 的開源靶場

KOAD（Kubernetes Offensive and Active Defense Lab）是本系列的核心專案：

• 35 個攻擊場景，覆蓋 ATT&CK Containers Matrix 全部 10 個戰術、28 個技術
• 每個場景可操作——不是紙上談兵，而是真正的 kubectl apply + 手動攻擊
• 攻防對照——每個攻擊場景都有對應的防禦對策和 Falco 偵測規則
• 一鍵部署——bash setup.sh 在 Minikube 上 5 分鐘內完成全部場景

部署前：認識你的工具箱

在動手之前，先認識這次會用到的工具——每一個都有明確的角色：

kubectl 新手必備指令

# 列出 Pod
kubectl get pods -n koad              # 指定 Namespace
kubectl get pods -A                   # 所有 Namespace

# 查看詳細資訊（除錯必備）
kubectl describe pod <name> -n koad

# 查看 Pod 日誌
kubectl logs <name> -n koad           # 一次性
kubectl logs -f <name> -n koad        # 持續追蹤（像 tail -f）

# 進入容器（本系列最常用）
kubectl exec -it <name> -n koad -- bash
#   -i = 互動模式, -t = 分配終端, -- 後面是容器內指令

# 套用 / 刪除 YAML
kubectl apply -f pod.yaml
kubectl delete -f pod.yaml

# 我有什麼權限？
kubectl auth can-i --list

YAML 語法速學

K8s 的所有資源都用 YAML 定義。每個 K8s YAML 都有四個固定欄位：

apiVersion: v1              # API 版本
kind: Pod                   # 資源類型（Pod / Deployment / Service...）
metadata:                   # 元資料（名稱、標籤、Namespace）
  name: my-pod
  namespace: koad
spec:                       # 規格（你想要什麼）
  containers:
    - name: web
      image: nginx:1.25

YAML 注意事項：

• 縮排必須用空格，不能用 Tab
• 冒號後面要有空格：name: value（對）、name:value（錯）
• 清單用 - 開頭：每個 - 是一個元素

KOAD 靶場部署實戰

接下來是動手時間。以下步驟會在你的本地環境建立一座完整的攻防靶場。

Step 0：取得 KOAD 靶場原始碼

KOAD 靶場是一個獨立的 GitHub 專案，包含所有場景 YAML、靶機應用、防禦配置。第一步是把它 clone 下來：

# 主機終端
git clone https://github.com/fei3363/koad.git
cd koad

什麼是 git clone？ 就是把 GitHub 上的專案完整下載到你的電腦。執行後會在目前資料夾建立一個 koad/ 資料夾，裡面包含所有檔案。後續所有指令都在這個目錄下執行。

Clone 完成後，目錄結構如下：

koad/
├── setup.sh               # 一鍵部署（可選，自動執行下面所有步驟）
├── teardown.sh             # 清理環境
├── scenarios/              # 35 個攻擊場景 YAML
│   ├── initial-access/     # S01-S03
│   ├── execution/          # S04-S08
│   ├── persistence/        # S09-S12
│   └── ...                 # 共 10 個戰術目錄
├── apps/                   # 靶機應用程式原始碼 + Dockerfile
├── defense/                # 防禦元件（Falco、Kyverno、seccomp...）
├── attacker/               # 攻擊者工具箱
└── images/                 # 攻擊用容器映像

快速部署捷徑： 如果你想跳過手動步驟，直接 bash setup.sh 會自動執行 Step 1-7 的全部內容。但建議第一次跟著手動操作，理解每一步在做什麼。

環境需求

硬體：

軟體：

Step 1：安裝工具鏈

Linux（Ubuntu / Debian）

# 主機終端
# Docker
sudo apt-get update
sudo apt-get install -y docker.io
sudo systemctl enable docker && sudo systemctl start docker
sudo usermod -aG docker $USER
# 執行完後，登出再登入（或 newgrp docker）讓群組生效

# Minikube
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

# kubectl
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install kubectl /usr/local/bin/kubectl

# Helm（推薦 snap，可繞過某些網路問題）
sudo snap install helm --classic

macOS

# 主機終端（需要先安裝 Homebrew：https://brew.sh）
brew install minikube kubectl helm

# Docker：macOS 需要 Docker Desktop
# 下載安裝：https://www.docker.com/products/docker-desktop/
# 安裝後開啟 Docker Desktop，確認 Docker Engine Running

Windows

# PowerShell（以系統管理員執行）
# 前提：啟用 WSL2（Windows Subsystem for Linux 2）
wsl --install

# 安裝 Docker Desktop（會自動使用 WSL2 後端）
# 下載：https://www.docker.com/products/docker-desktop/

# 使用 winget 安裝其他工具
winget install Kubernetes.minikube
winget install Kubernetes.kubectl
winget install Helm.Helm

# 建議在 WSL2 的 Ubuntu 環境中操作，體驗最接近 Linux

驗證安裝（全平台通用）

# 主機終端
docker version --format '{{.Client.Version}}'
kubectl version --client --short
minikube version --short
helm version --short

四個指令都顯示版本號就表示安裝完成。

Step 2：啟動 Minikube 叢集

# 主機終端
minikube start \
  --driver=docker \
  --cpus=4 \
  --memory=8192 \
  --kubernetes-version=v1.30.0 \
  --cni=calico

參數考量：

• --driver=docker：Docker driver 最穩定，但容器逃逸場景會受限於 Docker-in-Docker
• --cni=calico：選用 Calico 是因為它支援 NetworkPolicy（Minikube 預設 CNI 不支援）
• --kubernetes-version=v1.30.0：固定版本確保場景行為一致

等待 Node 就緒：

# 主機終端
kubectl wait --for=condition=Ready node/minikube --timeout=120s

踩坑 #1：Node NotReady
Calico CNI 需要時間啟動。剛跑完 minikube start 就用 kubectl get nodes 會看到 NotReady。等 30–60 秒讓 Calico Pod 完全啟動即可。

Step 3：建立 Namespace

# 主機終端
for ns in koad koad-attack koad-defense koad-registry koad-production; do
  kubectl create namespace "$ns"
done

Step 4：建構自訂映像

# 主機終端
# SSRF 漏洞 Web App（Day 2 會詳細解說）
minikube image build -t koad/vulnerable-webapp:latest apps/vulnerable-webapp/

# 模擬雲端 Metadata API
minikube image build -t koad/mock-metadata:latest apps/mock-metadata/

# 暴力破解工具
minikube image build -t koad/brute-forcer:latest apps/brute-forcer/

踩坑 #2：Docker 權限問題
如果你使用 snap 安裝的 Docker，直接 docker build 會遇到 permission denied 讀不到 ~/.minikube/certs/ca.pem。解法是使用 minikube image build——它直接在 Minikube VM 裡建構，不需要本地 Docker 存取 Minikube 的憑證。

Step 5：部署 35 個攻擊場景

# 主機終端 — 一次部署全部場景
for dir in initial-access execution persistence privilege-escalation \
           stealth defense-impairment credential-access discovery \
           lateral-movement impact; do
  kubectl apply -f scenarios/$dir/
done

驗證部署：

$ kubectl get pods -n koad
NAME                                    READY   STATUS      AGE
attacker                                1/1     Running     38m
brute-forcer                            1/1     Running     38m
cred-stealer                            1/1     Running     38m
critical-app-5776fdb957-dfxqr           1/1     Running     38m
dind-escape                             1/1     Running     38m
monitoring-agent-775b8dc8d4-rd7fv       1/1     Running     38m  ← S35 挖礦偽裝
privileged-pod                          1/1     Running     38m
...

踩坑 #3：bitnami/kubectl:1.30 not found
Bitnami 的映像 tag 命名規則變更，1.30 已不是有效 tag。解法：

sed -i 's|bitnami/kubectl:1.30|bitnami/kubectl:latest|g' scenarios/**/*.yaml

踩坑 #4：kube-system PodSecurity 限制
S22 偽裝 Pod 原本要部署到 kube-system（模擬真實攻擊），但 K8s 1.25+ 對 kube-system 啟用 PodSecurity Standards（Restricted level），Pod 會被立即刪除。解法是改部署到 koad namespace，在文章中說明真實攻擊的行為。

Step 6：部署防禦堆疊

Falco — Runtime 威脅偵測

Falco 是什麼？ 雲原生的即時安全監控工具（CNCF 專案）。它在 Linux 核心層監聽系統呼叫（syscall）——容器內的任何動作（讀檔案、開 socket、執行指令）最終都要呼叫核心，Falco 就在那裡攔截並比對規則。偵測到異常就發告警，像大樓的監視器——不能阻止入侵，但第一時間通知你。

在本系列中，每次攻擊步驟旁邊的 Falco 觀察 就是 Falco 產生的告警。

# 主機終端
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

helm install falco falcosecurity/falco \
  -n falco --create-namespace \
  -f defense/falco/values-custom.yaml

KOAD 的 Falco 配置重點：

• driver: modern_ebpf——使用 eBPF 而非 kernel module，Docker-in-Docker 環境更穩定
• Falcosidekick UI: 啟用，提供告警視覺化介面
• 26 條自訂規則: 覆蓋容器逃逸、kubectl 執行、SA Token 讀取、挖礦偵測等場景

踩坑 #5：Falco chart v9 棄用 gRPC 設定
Falco 0.44+ 的 Helm chart 移除了 falco.grpc 和 falco.grpc_output 設定。如果你從舊版 values 複製過來，會遇到 template 錯誤。移除這兩個區塊即可。

踩坑 #6：rules_file 與 rules_files 衝突
Falco 0.44 使用 rules_files（複數），Helm chart 會自動設定。如果你在 values 裡又寫了 rules_file（單數），會因為兩者同時存在而報驗證錯誤。自訂規則改用 customRules 區塊。

踩坑 #7：inotify handler 初始化失敗
Minikube Docker driver 環境中，inotify 的 max_user_instances 受限。解法是在 values 中設定 watch_config_files: false，或在主機上 sudo sysctl -w fs.inotify.max_user_instances=1024。

驗證 Falco 規則觸發：

$ kubectl logs -n falco -l app.kubernetes.io/name=falco --tail=5

{"rule":"KOAD S05 kubectl Execution in Container","priority":"Critical",...}
{"rule":"KOAD S26 SA Token Read","priority":"Warning",...}
{"rule":"KOAD S13 Privileged Container Started","priority":"Critical",...}

Kyverno — Kubernetes 原生策略引擎

Kyverno 是什麼？ K8s 原生的 Policy-as-Code 引擎。當有人 kubectl apply 建立 Pod 時，Kyverno 在 API Server 前面攔截請求，檢查是否符合安全策略——像機場安檢門，不合規的 Pod 直接被拒絕（Enforce 模式）或記錄在案（Audit 模式）。KOAD 使用 Audit 模式，讓攻擊能執行但記錄違規。

# 主機終端
helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update

helm install kyverno kyverno/kyverno \
  -n kyverno --create-namespace

# 部署 KOAD 策略（Audit 模式）
kubectl apply -f defense/kyverno/policies.yaml

KOAD 的 7 條 Kyverno 策略（全部 Audit 模式，不阻擋，只記錄）：

為什麼用 Audit 而不是 Enforce？因為 KOAD 是攻防靶場——攻擊場景本身就是「違規」的。Audit 模式讓攻擊能正常執行，同時記錄所有違規事件，方便後續分析。

NetworkPolicy

# 主機終端
kubectl apply -f defense/network-policies/default-deny.yaml

部署 4 條策略：

• default-deny-all：預設阻擋所有進出流量
• allow-dns：允許 DNS 查詢
• allow-ssrf-webapp-ingress：允許 SSRF webapp 的 ingress
• block-metadata-api：阻擋 169.254.169.254 metadata API 存取

部署後驗證

全部部署完成後，確認以下指標：

# Pod 狀態
$ kubectl get pods -n koad | grep -c Running
37

# Falco
$ kubectl get pods -n falco
falco-xxxxx                 2/2   Running
falco-falcosidekick-xxxxx   1/1   Running

# Kyverno
$ kubectl get cpol | head -5
NAME                             ADMISSION   BACKGROUND   READY
koad-block-host-namespaces       true        true         True
koad-block-hostpath              true        true         True
koad-block-privileged            true        true         True
...

# NetworkPolicy
$ kubectl get networkpolicies -n koad
default-deny-all           ...
allow-dns                  ...

KOAD 靶場架構總覽

存取靶場服務

磁碟空間管理

KOAD 拉取的映像 + 建構的容器會佔用大量磁碟空間。如果遇到 Docker is out of disk space：

docker system df           # 檢查使用情況
docker system prune -a -f --volumes   # 清理未使用的映像

建議在部署前確保至少有 50 GB 可用空間。

清除靶場

# 清除所有 KOAD 資源
bash teardown.sh

# 完全刪除 Minikube 叢集
minikube delete

30 天文章導覽

學習路線建議

不需要依序讀完 30 天。根據你的目標選擇路線：

路線 A：初學者快速上手（9 天）

Day 1 → 2 → 3 → 4 → 5 → 8 → 12 → 24 → 30

先建立攻防全景觀，體驗一條完整的攻擊鏈，再看防禦手段。跳過進階逃逸和隱匿手法。

路線 B：完整學習（30 天）

Day 1 → 2 → 3 → ... → 30（依序）

攻擊與防禦交替，每個戰術都有動手實作。適合想全面掌握 K8s 安全的讀者。

路線 C：CKS 考試準備（13 天）

Day 1 → 3 → 5 → 7 → 12 → 13 → 16 → 17 → 22 → 23 → 25 → 27 → 29

聚焦防禦側，涵蓋 CKS 六大領域：Cluster Setup、Hardening、System Hardening、Microservice、Supply Chain、Monitoring。

前置條件

常見問題排除

術語表

本系列常出現的術語快速參照：

本日小結

完成度自我檢查

• [ ] 能說出 ATT&CK Containers Matrix 的 10 個戰術名稱
• [ ] Minikube 叢集已啟動且 Node Ready
• [ ] 5 個 Namespace 已建立（koad / koad-attack / koad-defense / koad-registry / koad-production）
• [ ] 35 個攻擊場景 Pod 大部分為 Running 狀態
• [ ] Falco Pod 正常運行且有告警輸出
• [ ] Kyverno 7 條策略已 Ready
• [ ] NetworkPolicy 4 條策略已套用
• [ ] 能存取 SSRF Webapp（minikube service ssrf-webapp -n koad --url）

今日重點回顧

1. ATT&CK Containers Matrix 全景——10 個戰術、28 個技術，每個技術都對應 KOAD 場景
2. KOAD 靶場實際部署——35 場景 + Falco + Kyverno + NetworkPolicy，記錄 7 個踩坑

明天開始進入正題——Day 2 從 TA0001 Initial Access 開始，實際操作 SSRF 攻擊、kubelet 探測和 kubeconfig 洩漏三條入侵路徑。