2 files changed, 2 insertions(+), 2 deletions(-)

M Sections/2.Backgrounds.tex
M Sections/4.Architecture.tex

@@ 68,7 68,7 @@ Kubernetes 主要透過兩個機制達成使用者的存取控制，其一是 RB
 
 Kubernetes 內建許多 admission controllers，其中一些用來實做基本功能並預設啟用，如資源配額的部份邏輯。另外也有些預設停用的 admission controllers，提供給管理者進行平台加固或者調整行為使用。
 
-對於內建的 admission controllers 不敷使用的場合，Kubernetes 提供兩個機制讓管理者進一步自訂邏輯：webhooks 與 Common Expression Language\cite{cel} （簡稱 CEL）。Webhooks 透過呼叫管理者提供的 HTTP API 達成，支援 mutating 與 validating，可以透過任何能架設 HTTP API 的語言編寫，在生態系上已經有多個框架可以協助開發，例如：Open Policy Agent 與 Kyverno 等。CEL 為一結構資料處理語言，常用以使軟體功能可程式化，Kubernetes 將其導入作為延伸 kube-apiserver 邏輯的手段。以 Kubernetes 1.31 而言，目前只有 validating 進入穩定狀態，對 mutating 的支援仍在測試階段 (alpha)。相對於 webhooks，使用 CEL 可以直接在 kube-apiserver 上執行邏輯，省略了呼叫 HTTP API 的網路溝通，減少造成的延遲影響與管理負擔，但能夠進行的操作受限於 Kubernetes 對其執行環境提供的函式庫。
+對於內建的 admission controllers 不敷使用的場合，Kubernetes 提供兩個機制讓管理者進一步自訂邏輯：webhooks 與 Common Expression Language\cite{cel} （簡稱 CEL）。Webhooks 透過呼叫管理者提供的 HTTP API 達成，支援 mutating 與 validating，可以透過任何能架設 HTTP API 的語言編寫，在生態系上已經有多個框架可以協助開發，例如：Open Policy Agent 與 Kyverno 等。CEL 為一結構資料處理語言，常用以使軟體功能可程式化，Kubernetes 將其導入作為延伸 kube-apiserver 邏輯的手段。以 Kubernetes 1.31 而言，目前只有 validating 進入穩定狀態，對 mutating 的支援仍在開發。相對於 webhooks，使用 CEL 可以直接在 kube-apiserver 上執行邏輯，省略了呼叫 HTTP API 的網路溝通，減少造成的延遲影響與管理負擔，但能夠進行的操作受限於 Kubernetes 對其執行環境提供的函式庫。
 
 \section{Helm}
 

@@ 109,7 109,7 @@ Kubernetes 中容器 images 的下載策略（\verb|imagePullPolicy| 欄位）
 
 每個使用者會創立一個與其系計中帳號名稱相同的 User，其中 \verb|spec| 的 \verb|profile| 欄位帶有身份組資訊，影響資源配額的大小，由網頁界面自動判斷填入。對於創立代表自身 User 所需的權限，我們透過 RBAC 允許所有使用者創立 User，再透過 admission control 將其限制名稱必須與身份相同。兩階段的設計有助於簡化 RBAC 實做，使 RBAC 實做上不須枚舉使用者名稱一一事先對應，同時也大幅降低叢集上相關設定的 resources 個數，有助於減少管理上的負擔。對於 \verb|profile| 欄位的真實性，我們一樣透過 admission control 與身份資訊比對證實。
 
-就 \verb|profile| 欄位而言，還有另一個可行的方法，即是以 mutating admission control 由叢集端判斷寫入，而不仰賴網頁界面邏輯。這個方式目前有個缺點：admission control 邏輯我們希望透過 CEL 實做，而以 CEL 實做 mutating 雖然已有相關機制，現今仍未進入穩定狀態。另外，透過網頁界面預填也使得 admission control 層只須實做 validating，相對於 mutating，validating 因不能修改 resource 內容，較為單純且有平行化處理的空間，在效能與管理上皆有些許優勢。
+就 \verb|profile| 欄位而言，還有另一個可行的方法，即是以 mutating admission control 由叢集端判斷寫入，而不仰賴網頁界面邏輯。這個方式目前有個缺點：admission control 邏輯我們希望透過 CEL 實做，而以 CEL 實做 mutating 相關機制尚未開發完成。另外，透過網頁界面預填也使得 admission control 層只須實做 validating，相對於 mutating，validating 因不能修改 resource 內容，較為單純且有平行化處理的空間，在效能與管理上皆有些許優勢。
 
 對於管理需求，我們在 admission control 實做保留了彈性，若操作者為管理者即不加以限制。管理者可以自行創立代表他人的 User，為其修改身份組，提供人工處理政策上例外的空間。另外，由 User 所產生的每個 resource 皆會採用 Kubernetes 的 \verb|ownerReferences| 機制。\verb|ownerReferences| 表現了一個 resource 被一個 owner resource 所管轄，當 owner resource 被刪除時，Kubernetes 的回收機制也會一併刪除此 resource。在我們的場景，由於使用者的資料皆為於個人專屬的 Namespace 底下，而 User 又為此 Namespace 的 owner resource，於是當使用者行為極端異常，管理者需要對其制裁時，只須刪除其 User 便可徹底清除此使用者的所作所為。