Validating Admission Policy（VAP）是Kubernetes 提供的一種原生准入控制機制。與依賴外部 Webhook 的 Gatekeeper 相比，VAP 在 kube-apiserver 內部直接執行規則校正，穩定性和效能更優。在 ACK 中，可在部署安全性原則時選擇 CEL 語言，啟用 VAP 作為策略執行引擎，以更高效、更穩定的方式保障叢集的資源安全與合規。
VAP工作原理
VAP作為 Kubernetes 內建的准入能力，允許通過聲明式的 CEL 運算式，在資來源物件建立或更新的請求被持久化前進行規則校正。不滿足條件的請求會被 kube-apiserver 直接拒絕。
ACK的安全性原則管理功能整合了 VAP（1.30 及以上版本預設啟用），其實現基於 Gatekeeper 的多策略引擎方案。當部署一個 CEL 語言的策略執行個體時，Gatekeeper 會將其自動轉換為一個原生的 ValidatingAdmissionPolicy資源。同時，原有的 Gatekeeper Webhook 會作為兜底機制存在，當 VAP 執行失敗時，請求會回退到 Webhook 進行二次校正，確保策略的持續有效。
VAP 與 Gatekeeper 的主要差異如下。
-
核心架構差異
維度
VAP
Gatekeeper
部署依賴
內建於 kube-apiserver，無需額外的Webhook。
需要額外部署 Gatekeeper 控制面和 Webhook 組件。
執行鏈路
在 kube-apiserver 內部執行，無網路開銷。
通過 Validating Webhook 回調外部服務，存在網路延遲。
穩定性
更高，不依賴外部組件的運行狀態。
依賴 Gatekeeper 組件的穩定性。
規則語言
CEL（與 VAP/MAP 配套，運算式貼近 Kubernetes 對象結構）
Rego、CEL（多語言並存）
-
功能支援情況
維度
VAP
Gatekeeper
審計能力（存量資源）
不支援
支援
外部資料源
不支援，規則僅能訪問請求中的對象資料
支援，可通過
external_data引用其他資源或外部資料資源變更（Mutate）
支援（通過 MAP, Kubernetes 1.30 中為 Alpha 階段）
支援（通過其 CRD 實現）
“Warn”非阻斷治理
支援 (
validationActions: [Warn])支援
“Dry-run”試運行
支援（通過kube-apiserver 的 dry-run 機制）
支援
豁免/排除機制
支援（
match/exclude規則）支援（
match/exclude、label等方式）事件/訂閱
無原生事件機制
支援，提供違規日誌、審計事件等
在策略管理中啟用VAP
在策略管理中，可選擇策略語言來指定策略引擎，系統將自動基於對應的引擎來執行該策略。
-
Rego：對應 Gatekeeper 引擎。
-
CEL：對應 VAP 引擎。
在叢集列表頁面，單擊目的地組群名稱，然後在左側導覽列，選擇。
-
單擊我的策略，然後單擊建立策略執行個體，參見頁面提示配置策略執行個體。
首次建立CEL類型的策略執行個體時，需開啟VAP策略審計功能，以便可在策略實踐總覽查看VAP的執行結果。頁面預設展示7天內最近100條的攔截或警示日誌。如需查看更多日誌，請選擇營運管理 > 日誌中心，單擊控制面組件日誌頁簽，按照頁面提示選擇並查看 validating-admission-policy 日誌。
-
部署完成後，在策略實踐總覽頁面查看策略執行結果。
相關操作
修改已有策略的執行引擎
已有策略的策略語言支援修改。但一個原則範本下的所有執行個體必須使用統一的執行語言，修改該模板的語言將導致其所有執行個體同步變更。
-
控制台：在我的策略頁面的策略列表中，定位目標策略的策略語言，單擊修改並選擇新的語言。
-
OpenAPI：參見DeployPolicyInstance查詢、部署、修改和刪除策略庫中的策略執行個體。