映像檔掃描與威脅模型在部署前提供保護。Admission policy 在 workload 進入叢集那一刻提供保護。Runtime monitor 則是在那之後監看一切的攝影機。
叢集中的三層防護
| 層級 | 職責 | 工具 |
|---|---|---|
| Pre-admission | Lint、掃描映像檔、驗證簽署 | Trivy、Cosign |
| Admission | 擋下違反 policy 的 workload | Kyverno、OPA Gatekeeper |
| Runtime | 偵測異常行為、network policy | Falco、Cilium Tetragon、NetworkPolicy |
Kyverno vs OPA Gatekeeper——選哪個?
- Kyverno:用純 YAML 撰寫 policy,簡短易學。支援 mutate、generate、verifyImages keyless。多數場景都適用。
- OPA Gatekeeper:以 Rego 撰寫,對複雜邏輯較強。適合已經有 OPA 生態系 (API gateway、microservice authz) 的環境。
建議:新叢集從 Kyverno 開始。日後遷移不算困難,因為 policy 本身就是宣告式的。
應該具備的基線 policy
- 在應用程式 namespace 套用 Pod Security Standards: restricted。
- 禁止使用
privileged: true、hostNetwork、hostPID的 Pod。 - 要求映像檔來自內部 registry (allowlist)。
- 要求每個 container 都有
resources.requests/limits。 - 要求標準 label (team、env、cost-center) 以利成本追蹤與 IR。
- 對 production 映像檔驗證 Cosign 簽署。
安全部署:Audit → Fix → Enforce
絕對不要在運行中的叢集上一次套用 validationFailureAction: Enforce。參考流程:
- 先以
validationFailureAction: Audit套用 policy。 - 透過 Kyverno PolicyReport CRD 在 1-2 週內量測違規數。
- 為每個違規的 workload 開單修復,指派 owner。
- 當 staging 環境違規數歸零後,依 dev → staging → prod 順序切換為 Enforce。
建立明確的例外流程:特殊 workload (例如 privileged debug pod) 必須帶有 annotation 註明理由、到期日、owner。
Network policy default-deny
每個應用程式 namespace 都應從一條「deny all」policy 開始,再依實際需求逐步打開:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: payments
spec:
podSelector: {}
policyTypes: ["Ingress", "Egress"]
之後再逐條開放需要的連線:app → DB、app → service mesh、透過 egress gateway 連到外部 API。搭配 Cilium,policy 可做到 L7 (HTTP path、gRPC method、Kafka topic),比僅靠 port/IP 強大許多。
Falco:容器的 runtime 偵測
Falco 透過 kernel (eBPF 或 kernel module) 觀察 syscall。最有價值的幾條規則:
- 容器內出現 shell:
shell_in_container。Production 中很少有合理理由出現 shell。 - 修改 runtime 映像檔中的 binary (淪陷跡象)。
- 異常的對外連線到 allowlist 之外的 IP/網域。
- 讀取敏感檔案例如
/etc/shadow、kubeconfig。 - 掛載敏感路徑例如
/var/run/docker.sock、/proc。
把高 severity 規則的 Falco 事件串到 Slack/PagerDuty,其他則送到 SIEM 做後續分析。
Cilium Tetragon:hardware-assisted、低額外負擔
Tetragon 同樣使用 eBPF,但針對大型叢集做了效能優化,而且能直接執行 (enforce)而不只是偵測 (例如:當 syscall 違規時直接 kill process)。適合需要 in-kernel response time 的場景。
當警報響起——簡短的 IR workflow
- 15 分鐘內 triage:依 severity 分辨 true/false positive。
- 用
NetworkPolicy擋掉 egress 隔離 Pod,不要立刻刪除 (會丟失證據)。 - 採取快照:
kubectl debug、dump memory、複製日誌、匯出 audit trail。 - 輪換 Pod 可能接觸過的憑證:ServiceAccount token、掛載的 secret。
- 調查結束後:寫無責備 (blameless) 的 post-mortem,必要時新增 Falco 規則。
結論
守護 Kubernetes 不只是 RBAC 與防火牆。需要三層:pre-admission (映像檔掃描、簽署)、admission (Kyverno)、runtime (Falco/Tetragon、NetworkPolicy)。從 audit 模式的基線 policy 開始,逐步轉為 enforce,並把 Falco 與 SIEM 整合——這就是 2026 年大多數 production 叢集足夠堅固的配置。