偵測只是第一步——自動回應才是防禦閉路的關鍵。

學習目標

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

• 部署 Falco Talon 並配置自動回應規則（隔離 / 終止 / 通知）
• 部署 Tetragon 並撰寫 TracingPolicy 進行 kernel-level enforcement
• 配置 K8s Audit Log Policy（四級 Level）並啟用 Webhook
• 比較三層偵測堆疊的偵測範圍與回應速度
• 觸發攻擊場景驗證三層偵測的協同運作

閱讀前置條件

本篇會串連 Falco、Tetragon、Audit Log 三層偵測。建議的最低閱讀量：

快速路徑：如果時間有限，至少讀完 Day 1 → 25 → 本篇。

三層偵測架構

為什麼需要三層

單一偵測層有盲區：

三層堆疊的覆蓋率：Falco 處理 80% 的 runtime 偵測，Audit Log 補上 API 層，Tetragon 提供最底層的 kernel-level enforcement。

1. Falco Talon：自動回應引擎

為什麼需要自動回應

Day 25 的 Falco 規則可以偵測攻擊，但偵測到告警後需要人工處理——這在凌晨三點的 SOC 值班中不夠及時。Falco Talon 接收 Falco 告警，自動執行預定義的回應動作。

Talon 架構原理

Talon 的核心是一個事件驅動的規則引擎：

1. 接收：監聽 Falcosidekick 透過 HTTP webhook 傳來的告警
2. 匹配：根據 rule name 和 priority 比對預定義的回應規則
3. 執行：呼叫 K8s API 執行回應動作（建立 NetworkPolicy、刪除 Pod、標記 label）
4. 通知：將回應結果發送到指定通道

KOAD Falco Talon 配置

listenAddress: 0.0.0.0
listenPort: 2803

defaultNotifiers:
  - k8s

rules:
  # 偵測到挖礦 → 立即隔離
  - name: Isolate Cryptominer
    match:
      rules:
        - "KOAD S35 Cryptominer Process"
      priority: critical
    actions:
      - action: Label Pod
        parameters:
          labels:
            quarantine: "true"
      - action: NetworkPolicy
        parameters:
          allow:
            - "127.0.0.1/32"    # 只允許 localhost

  # 偵測到容器逃逸 → 立即終止
  - name: Terminate Escape Pod
    match:
      rules:
        - "KOAD S13 Privileged Container Started"
        - "KOAD S14 Cgroup Manipulation"
        - "KOAD S15 Docker Socket Access"
        - "KOAD S16 Core Pattern Modified"
        - "KOAD S17 Ptrace in Container"
        - "KOAD S18 Device Node Created"
      priority: critical
    actions:
      - action: Terminate Pod
        parameters:
          gracePeriodSeconds: 0    # 立即終止

  # 偵測到暴力破解 → 標記告警
  - name: Alert Brute Force
    match:
      rules:
        - "KOAD S24 Brute Force Attempt"
      priority: critical
    actions:
      - action: Label Pod
        parameters:
          labels:
            security-alert: brute-force

  # 偵測到橫向移動 → 完全隔離
  - name: Isolate Lateral Movement
    match:
      rules:
        - "KOAD S30 Cross-Namespace Secret Access"
      priority: critical
    actions:
      - action: NetworkPolicy
        parameters:
          allow: []    # 完全隔離

Talon 回應動作

部署 Falco Talon

# 主機終端
# 1. 部署 Falco Talon
$ helm install falco-talon falco-talon/falco-talon \
    -n falco \
    --set-file config.config=defense/falco-talon/config.yaml

# 2. 配置 Falco 將告警轉發到 Talon
# falco values-custom.yaml:
falcosidekick:
  enabled: true
  config:
    webhook:
      address: "http://falco-talon:2803"

# 3. 驗證 Talon 已正常啟動
$ kubectl get pods -n falco | grep talon
falco-talon-7f8d9c6b4-x2k9p   1/1     Running   0   30s

# 4. 查看 Talon 日誌確認規則載入
$ kubectl logs -n falco -l app=falco-talon --tail=10
2026-08-19T10:00:01Z INF  Listening on 0.0.0.0:2803
2026-08-19T10:00:01Z INF  Loaded 4 rules
2026-08-19T10:00:01Z INF  Default notifiers: [k8s]

Talon RBAC 配置

Talon 需要足夠的權限來執行回應動作：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: falco-talon
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "delete", "update", "patch"]
  - apiGroups: [""]
    resources: ["pods/exec"]
    verbs: ["create"]
  - apiGroups: ["networking.k8s.io"]
    resources: ["networkpolicies"]
    verbs: ["get", "list", "create", "update", "delete"]
  - apiGroups: [""]
    resources: ["events"]
    verbs: ["create"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: falco-talon
subjects:
  - kind: ServiceAccount
    name: falco-talon
    namespace: falco
roleRef:
  kind: ClusterRole
  name: falco-talon
  apiGroup: rbac.authorization.k8s.io

回應時間線

驗證 Talon 完整流程

部署完成後，觸發一個攻擊場景驗證 Talon 自動回應：

# 主機終端
# 觸發 S13（特權容器）攻擊，觀察 Talon 回應
kubectl apply -f scenarios/privilege-escalation/S13-privileged-pod.yaml

# 等待 5 秒後檢查 Talon 是否自動終止了 Pod
sleep 5
kubectl get pods -n koad -l koad-scenario=S13

預期結果：

NAME               READY   STATUS        RESTARTS   AGE
privileged-pod     0/1     Terminating   0          5s

Talon 收到 Falco 的 KOAD S13 Privileged Container Started 告警後，自動執行了 Terminate Pod 動作。

# 確認 Talon 日誌記錄了回應動作
kubectl logs -n falco -l app=falco-talon --tail=5

預期結果：

2026-08-19T10:00:06Z INF  Received event: "KOAD S13 Privileged Container Started"
2026-08-19T10:00:06Z INF  Matched rule: "Terminate Escape Pod"
2026-08-19T10:00:06Z INF  Action: Terminate Pod (gracePeriodSeconds: 0)
2026-08-19T10:00:06Z INF  Pod koad/privileged-pod terminated

Talon 回應動作的陷阱

2. Tetragon：eBPF 精確追蹤

Falco vs Tetragon

Tetragon 部署

# 主機終端
# 使用 Helm 部署 Tetragon
$ helm repo add cilium https://helm.cilium.io
$ helm install tetragon cilium/tetragon \
    -n kube-system \
    --set tetragon.btf=/sys/kernel/btf/vmlinux

# 驗證
$ kubectl get pods -n kube-system | grep tetragon
tetragon-operator-6b9d8c7f4-q2k8p   1/1     Running   0   45s
tetragon-node-agent-xk9p2            1/1     Running   0   45s

# 安裝 tetra CLI（用於查看事件）
$ GOOS=$(go env GOOS) GOARCH=$(go env GOARCH)
$ curl -L https://github.com/cilium/tetragon/releases/latest/download/tetra-${GOOS}-${GOARCH}.tar.gz | tar -xz
$ sudo mv tetra /usr/local/bin/

驗證 Tetragon 部署

# 主機終端
# 確認 Tetragon Pod 正常運行
kubectl get pods -n kube-system -l app.kubernetes.io/name=tetragon

預期結果：

NAME                                  READY   STATUS    RESTARTS   AGE
tetragon-operator-6b9d8c7f4-q2k8p    1/1     Running   0          2m
tetragon-node-agent-xk9p2            1/1     Running   0          2m

# 測試 Tetragon 事件串流
kubectl exec -n kube-system ds/tetragon -- tetra getevents -o compact --timeout 10

預期結果：

process default/test-pod /bin/sh
process default/test-pod /usr/bin/ls
exit    default/test-pod /usr/bin/ls 0

如果看到 process 事件，代表 Tetragon 已正確掛載 eBPF 探測器並追蹤容器行為。

TracingPolicy 範例

偵測 SA Token 讀取

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: detect-sa-token-read
spec:
  kprobes:
    - call: "security_file_open"
      syscall: false
      args:
        - index: 0
          type: file
      selectors:
        - matchArgs:
            - index: 0
              operator: "Equal"
              values:
                - "/var/run/secrets/kubernetes.io/serviceaccount/token"

偵測 execve + 自動 SIGKILL

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-dangerous-binaries
spec:
  tracepoints:
    - subsystem: "syscalls"
      event: "sys_enter_execve"
      args:
        - index: 0
          type: "string"
      selectors:
        - matchArgs:
            - index: 0
              operator: "Equal"
              values:
                - "/usr/bin/nmap"
                - "/usr/bin/hydra"
                - "/usr/local/bin/xmrig"
          matchActions:
            - action: Sigkill    # 立即 kill process

偵測網路連線到可疑連接埠

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: detect-suspicious-connect
spec:
  kprobes:
    - call: "tcp_connect"
      syscall: false
      args:
        - index: 0
          type: "sock"
      selectors:
        - matchArgs:
            - index: 0
              operator: "DPort"
              values:
                - "4444"     # Metasploit
                - "5555"     # C2
                - "9050"     # Tor SOCKS

偵測容器逃逸相關 syscall

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: detect-container-escape
spec:
  kprobes:
    - call: "security_sb_mount"
      syscall: false
      args:
        - index: 0
          type: "string"
        - index: 1
          type: "path"
      selectors:
        - matchArgs:
            - index: 0
              operator: "Equal"
              values:
                - "/dev/sda1"
                - "/dev/vda1"
          matchActions:
            - action: Sigkill
    - call: "__x64_sys_ptrace"
      syscall: true
      args:
        - index: 0
          type: "int"
      selectors:
        - matchArgs:
            - index: 0
              operator: "Equal"
              values:
                - "16"    # PTRACE_ATTACH
                - "17"    # PTRACE_SEIZE
          matchActions:
            - action: Sigkill

Tetragon 的 Process 樹追蹤

Tetragon 最強大的功能之一是完整的 process 樹追蹤。當偵測到可疑行為時，你可以看到從 container entrypoint 到 exploit binary 的完整呼叫鏈：

# 主機終端
# 查看 Tetragon 事件（compact 模式）
$ kubectl exec -n kube-system ds/tetragon -- \
    tetra getevents -o compact

process koad/attacker /bin/bash
process koad/attacker /usr/bin/curl http://169.254.169.254/...
[connect] koad/attacker /usr/bin/curl tcp 169.254.169.254:80
process koad/attacker /usr/bin/kubectl get secrets -A
[open]     koad/attacker /usr/bin/kubectl /var/run/secrets/.../token
process koad/attacker /usr/bin/nmap -sT 10.96.0.0/16
[exit]     koad/attacker /usr/bin/nmap SIGKILL

Tetragon 的優勢

Tetragon 在 kernel 層面就能 kill process，攻擊者甚至來不及完成 syscall。對比 Falco + Talon 需要經過多個元件的傳遞，Tetragon 的 enforcement 幾乎是即時的。

3. Audit Log：API 層偵測

Audit Policy 四級配置

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # Level 1: 記錄 Secret 的所有操作（但不記錄 body）
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets"]

  # Level 2: 記錄 RBAC 變更（含完整內容）
  - level: RequestResponse
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["clusterrolebindings", "rolebindings"]
    verbs: ["create", "update", "delete", "patch"]

  # Level 3: 記錄 Pod/Deployment 的建立和刪除
  - level: Request
    resources:
      - group: ""
        resources: ["pods"]
      - group: "apps"
        resources: ["deployments", "daemonsets"]
    verbs: ["create", "delete"]

  # Level 4: 忽略健康檢查和心跳
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]

  # Level 5: 其他所有操作記錄 Metadata
  - level: Metadata

啟用 Audit Log（kubeadm）

# 編輯 /etc/kubernetes/manifests/kube-apiserver.yaml，加入以下參數：
--audit-policy-file=/etc/kubernetes/audit-policy.yaml
--audit-log-path=/var/log/kubernetes/audit/audit.log
--audit-log-maxage=30
--audit-log-maxbackup=10
--audit-log-maxsize=100

# 掛載 volume
volumeMounts:
  - mountPath: /etc/kubernetes/audit-policy.yaml
    name: audit-policy
    readOnly: true
  - mountPath: /var/log/kubernetes/audit
    name: audit-log
volumes:
  - name: audit-policy
    hostPath:
      path: /etc/kubernetes/audit-policy.yaml
      type: File
  - name: audit-log
    hostPath:
      path: /var/log/kubernetes/audit
      type: DirectoryOrCreate

四個 Level 的差異

Audit Log 實際輸出分析

以 S09（RBAC 竄改）為例，Audit Log 記錄了完整的攻擊行為：

{
  "kind": "Event",
  "apiVersion": "audit.k8s.io/v1",
  "level": "RequestResponse",
  "auditID": "a1b2c3d4-e5f6-7890",
  "stage": "ResponseComplete",
  "requestURI": "/apis/rbac.authorization.k8s.io/v1/clusterrolebindings",
  "verb": "create",
  "user": {
    "username": "system:serviceaccount:koad:attacker-sa",
    "groups": ["system:serviceaccounts", "system:authenticated"]
  },
  "objectRef": {
    "resource": "clusterrolebindings",
    "name": "koad-backdoor-admin",
    "apiGroup": "rbac.authorization.k8s.io"
  },
  "responseStatus": { "code": 201 },
  "requestObject": {
    "roleRef": {
      "kind": "ClusterRole",
      "name": "cluster-admin"
    },
    "subjects": [{
      "kind": "ServiceAccount",
      "name": "backdoor-sa",
      "namespace": "koad"
    }]
  },
  "requestReceivedTimestamp": "2026-08-19T14:33:22.123456Z"
}

這筆 Audit Log 記錄了攻擊者用 attacker-sa 建立了 koad-backdoor-admin ClusterRoleBinding，把 backdoor-sa 綁定到 cluster-admin。有了 RequestResponse level，請求 body 完整保留。

Webhook Backend：即時轉發

# /etc/kubernetes/audit-webhook.yaml
apiVersion: v1
kind: Config
clusters:
  - name: audit-webhook
    cluster:
      server: https://siem.company.com/k8s-audit
users:
  - name: audit-webhook
    user:
      token: "webhook-token"
contexts:
  - context:
      cluster: audit-webhook
      user: audit-webhook
    name: audit-webhook
current-context: audit-webhook

# API Server 參數
--audit-policy-file=/etc/kubernetes/audit-policy.yaml
--audit-webhook-config-file=/etc/kubernetes/audit-webhook.yaml
--audit-webhook-batch-max-wait=5s

Audit Log 可偵測的 KOAD 場景

其他值得關注的安全工具

Falco + Tetragon + Audit Log 是目前最成熟的偵測組合，但 K8s 安全生態還有幾個值得關注的工具：

選型建議：

• 已有 Falco + Tetragon → 加 KubeArmor 補「阻擋」能力（Falco 偵測 + KubeArmor 阻擋 = 完整 NIST detect + respond）
• 跨團隊 / 多叢集 → SPIFFE/SPIRE 解決「Pod 怎麼證明自己是誰」的問題
• NetworkPolicy 不確定有沒有生效 → Hubble 的 hubble observe 直接看封包命運

三層偵測覆蓋比較

建議部署組合

效能影響實測

在 KOAD 靶場（4 CPU / 8GB Minikube）上的實測資料：

踩坑記錄

坑 1：Falco modern_ebpf 在舊核心上失敗

# 主機終端
# 現象
$ kubectl logs -n falco ds/falco
Error: failed to open eBPF probe

# 原因：核心版本 < 5.8 不支援 modern_ebpf
$ uname -r
5.4.0-150-generic

# 解法：改用 kmod driver
# values-custom.yaml:
driver:
  kind: kmod

坑 2：Tetragon TracingPolicy 拼寫錯誤無告警

# 主機終端
# 現象：部署 TracingPolicy 成功但沒有事件
$ kubectl apply -f policy.yaml
tracingpolicy.cilium.io/detect-sa-token-read created

# 原因：kprobes.call 拼錯了函數名，Tetragon 靜默忽略
# 排查：
$ kubectl logs -n kube-system ds/tetragon | grep -i error
WARN  kprobe "security_file_openn" not found

# 解法：確認 kernel function 存在
$ kubectl exec -n kube-system ds/tetragon -- \
    cat /proc/kallsyms | grep security_file_open

坑 3：Audit Log 檔案增長過快

# 主機終端
# 現象：磁碟被 audit log 佔滿
$ du -sh /var/log/kubernetes/audit/
12G     /var/log/kubernetes/audit/

# 解法：設定大小和保留限制
--audit-log-maxage=7        # 只保留 7 天
--audit-log-maxbackup=3     # 最多 3 個備份
--audit-log-maxsize=100     # 單檔最大 100MB

CKS 考點

CKS 實戰提示

• Audit Policy 一定要會寫：考試常考「為某種資源設定特定 level 的 audit policy」
• 四個 level 的差異：None / Metadata / Request / RequestResponse，考試會問「哪個 level 記錄 request body」
• Falco 規則讀寫：考試可能給你一條 Falco 規則要你修改 condition 或 output
• 啟用 Audit Log：知道 API Server 需要哪些參數（--audit-policy-file、--audit-log-path）以及 volume mount

常見問題排除

真實環境 vs KOAD 靶場

在 KOAD 中部署 Falco/Tetragon 很快。真實環境的挑戰是規則調校和誤報處理——部署只是開始。

本日小結

完成度自我檢查

• [ ] Falco Talon 已部署且能接收 Falco 告警
• [ ] 能配置 Talon 回應規則（terminate / label / isolate）
• [ ] Tetragon 已部署且 TracingPolicy 能觸發
• [ ] 能區分三層偵測的偵測範圍與回應速度
• [ ] Audit Log Policy 已配置（至少能說明四個 Level 差異）
• [ ] 觸發攻擊場景驗證至少兩層偵測的協同運作

今日重點回顧

1. Falco + Talon：syscall 偵測 + 秒級自動回應（隔離、終止、通知）
2. Tetragon：eBPF 精確追蹤 + 毫秒級 enforcement（kernel 層面 SIGKILL）
3. Audit Log：API 層偵測 + Webhook 即時轉發到 SIEM

核心觀念：偵測→回應的時間差決定了攻擊的影響範圍。 從 Audit Log 的「事後分析」到 Falco Talon 的「秒級回應」再到 Tetragon 的「毫秒級阻擋」，越接近核心的偵測點回應越快、影響越小。

明天 Day 27 進入策略引擎全覆蓋——NetworkPolicy + Kyverno + CIS Benchmark。