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

M Sections/4.Architecture.tex
A assets/provisioning.png

@@ 111,6 111,12 @@ Kubernetes 中容器 images 的下載策略（\verb|imagePullPolicy| 欄位）
 
 每個使用者會創立一個與其系計中帳號名稱相同的 User，其中 \verb|spec| 的 \verb|profile| 欄位帶有身份組資訊，影響資源配額的大小，由網頁界面自動判斷填入。對於創立代表自身 User 所需的權限，我們透過 RBAC 允許所有使用者創立 User，再透過 admission control 將其限制名稱必須與身份相同。兩階段的設計有助於簡化 RBAC 實做，使 RBAC 實做上不須枚舉使用者名稱一一事先對應，同時也大幅降低叢集上相關設定的 resources 個數，有助於減少管理上的負擔。對於 \verb|profile| 欄位的真實性，我們一樣透過 admission control 與身份資訊比對證實。
 
+\begin{figure}[htb]
+    \centering
+    \includegraphics[width=\textwidth]{assets/provisioning.png}
+    \caption{權限自動開通整體流程圖}
+\end{figure}
+
 就 \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 便可徹底清除此使用者的所作所為。