From d0601ecfd34bd8c9117bdce24182487f8d9ee578 Mon Sep 17 00:00:00 2001 From: Pinghao Wu Date: Sun, 22 Sep 2024 11:44:16 +0800 Subject: [PATCH] Architecture: cel: add ingress --- Sections/4.Architecture.tex | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Sections/4.Architecture.tex b/Sections/4.Architecture.tex index 8196dc5..0613be3 100644 --- a/Sections/4.Architecture.tex +++ b/Sections/4.Architecture.tex @@ -93,9 +93,10 @@ CSKloud 達成一代願景中的開放使用者直接存取 Kubernetes API，使 以 CEL 實做 validating admission control 邏輯需要以 ValidatingAdmissionPolicy resource 先行定義，在以 ValidatingAdmissionPolicyBinding resource 將之啟用。圖 \ref{fig:code-pod-policy} 即為實做防止繞過排程的 ValidatingAdmissionPolicy。首先我們只對開放給使用者的 Namespace 進行限制，透過我們權限開通的設計，以具有 \verb|u-| 前綴來判斷。再來由於排程機制對 Pod 指定節點與使用者直接指定修改的欄位相同，我們需要避免限制到叢集系統本身。這點由於我們的權限規劃，使用者沒有列舉 Nodes 的權限，我們以此分別使用者與系統。最後我們檢查欄位狀況。% TODO check if updated -% TODO ingress +另一個需要自訂邏輯的場景是域名使用權的管控。針對用來設定反向代理的 Ingresses，我們一樣先判斷操作的 Namespace 是否為使用者面向的，再進一步進行限制。需要限制的有：禁止使用 \verb|defaultBackend| 欄位（全域、不符合任何規則時的 fallback route），以及所有反向代理規則中的 \verb|host| 必須要符合域名白名單。域名白名單的部份參考其餘政策相關內建 admission controllers 的設計，採用在 Namespace 上標記的白名單作為設定手段，後續再藉由 \ref{sec:provisioner} 權限開通設定此白名單。 \section{權限開通實做} +\label{sec:provisioner} \section{網頁界面實做} -- 2.45.2