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

M Sections/4.Architecture.tex
A assets/provisioner-user-spec.png

@@ 98,6 98,21 @@ CSKloud 達成一代願景中的開放使用者直接存取 Kubernetes API，使
 \section{權限開通實做}
 \label{sec:provisioner}
 
+使用者權限開通的主要流程為：建立一個 Namespace，對其設定配額，增加 admission controllers 政策相關標記，最終調整 RBAC 授予使用者此 Namespace 下的權限。為了將其自動化，我們規劃為拓展 Kubernetes API，使用自訂 resource 種類進行實做，此種類稱為 User。使用者登入網頁界面時會自動嘗試創立代表自身的 User，若已存在代表已開通完成不須另外動作。面對新創立的 User，我們撰寫的 controller 會實行上述的開通流程。
+
+\begin{figure}[htb]
+    \centering
+    \includegraphics[width=0.5\textwidth]{assets/provisioner-user-spec.png}
+    \caption{權限開通自訂 resource 種類 User spec 範例}
+    \label{fig:code-pod-policy}
+\end{figure}
+
+每個使用者會創立一個與其系計中帳號名稱相同的 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 內容，較為單純且有平行化處理的空間，在效能與管理上皆有些許優勢。
+
+對於管理需求，我們在 admission control 實做保留了彈性，若操作者為管理員即不加以限制。管理員可以自行創立代表他人的 User，為其修改身份組，提供人工處理政策上例外的空間。
+
 \section{網頁界面實做}
 
 進一步對網頁界面的需求分析，可以將網頁界面切分為兩大塊：支援 Helm 的通用 Kubernetes 網頁型客戶端，以及 CSKloud 特定的部份，包含權限開通元件的整合以及 CSKloud 平台面向使用者的文件等。其中 Kubernetes 客戶端很容易的就可以利用於其他場景，我們採取 open core 的策略，將其 Kubernetes 客戶端開放原始碼，以 MIT 授權條款\footnote{MIT license: 一個在網頁技術場域廣受歡迎的寬鬆型開放原始碼條款。}釋出，命名為 Sparkles\footnote{Sparkles 釋出於 \url{https://github.com/xdavidwu/sparkles} 。}，回饋於社會，使得非平台使用者也能受益，同時可以也利用開放原始碼社群的力量來茁壯平台的發展。