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

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

@@ 41,7 41,7 @@ Authenticating proxy 透過在 Kubernetes API 之前加一層 proxy 伺服器進
 
 其餘的手段皆是透過 token 進行身份驗證，但 token 本身有所不同。Static tokens 是在 Kubernetes 本身預先設定好一個 token 對應使用者名稱、所在群組的清單，token 本身通常採用一個隨機的字串。由於目前實做上更動這份清單需要重新啟動 kube-apiserver，這個方法較少人採用。Webhook tokens 則是透過管理者提供的 HTTPS API 去將 token 對應到相關資訊，比 static tokens 來的有彈性，可以動態更動不須重啟 kube-apiserver。
 
-ServiceAccount tokens 與 OpenID Connect tokens 則都是 JSON Web Token (JWT)，一個有經過簽章的 token 格式，裡面包含身份資訊與使用期限等，Kubernetes 透過驗證簽章來確保他的真實性。ServiceAccount 是一個 resources 種類，代表一個身份，但不支援群組，由此可以簽發 ServiceAccount tokens，刪除 ServiceAccount resources 可以撤銷全部由其發出的 tokens。簽發 ServiceAccount tokens 時也可以進一步綁定 Secrets 或 Pods，使用時會額外檢查這些 resources 是否存在，達成以 token 為單位的撤銷。由於可以透過 Kubernetes API 管理，ServiceAccount tokens 常用於自動化場景，也常用於 controllers 元件。由於 ServiceAccount tokens 採用標準的 JWT 格式，透過簽章即可確認真偽，也有自 Kubernetes 存取外部系統時，供外部系統驗證的應用。
+ServiceAccount tokens 與 OpenID Connect tokens 則都是 JSON Web Token (JWT)，一個有經過簽章的 token 格式，裡面包含身份資訊與使用期限等，Kubernetes 透過驗證簽章來確保他的真實性。ServiceAccount 是一個 resources 種類，代表一個身份，但不支援群組，由此可以簽發 ServiceAccount tokens，刪除 ServiceAccount resources 可以撤銷全部由其發出的 tokens。簽發 ServiceAccount tokens 時也可以進一步綁定 Secrets\footnote{Secret: Kubernetes resources 種類，提供資料儲存，本身並不帶有任何功能。} 或 Pods，使用時會額外檢查這些 resources 是否存在，達成以 token 為單位的撤銷。由於可以透過 Kubernetes API 管理，ServiceAccount tokens 常用於自動化場景，也常用於 controllers 元件。由於 ServiceAccount tokens 採用標準的 JWT 格式，透過簽章即可確認真偽，也有自 Kubernetes 存取外部系統時，供外部系統驗證的應用。
 
 OpenID Connect (OIDC) 則是一個基於 OAuth 框架衍生的身份驗證協定，常用於網頁應用場景，由中心化的伺服器進行驗證，將身份資訊授予其他應用使用，並且可以讓使用者管理對應用存取身份資料的授權。Kubernetes 本身並不實做 OIDC 協定，而是利用驗證流程 OIDC 伺服器所簽發的 JWT (\verb|id_token|) 進行驗證，並預期由客戶端處理 OIDC 協定相關操作。由於可以跟現有 OIDC server 整合，實做容易且使用者不須額外的註冊流程，常用於使用者的互動存取。
 


@@ 61,7 61,7 @@ Kubernetes 內建許多 admission controllers，其中一些用來實做基本
 
 Helm 是用來簡化 Kubernetes 上的應用部屬流程的工具，其手段是透過模板化，使得部屬上的設定可以透過更貼近應用本身的角度撰寫。在 Kubernetes 上，典型的部屬應用流程會牽涉多個 resources，例如：Deployment\footnote{Deployment: Kubernetes resources 種類，提供高層次的 Pod 管理，以實做 Pod 的更新與複製等。} 用以管控 Pods、Service 將 Pods 提供的服務集結做負載均衡、Ingress\footnote{Ingress: Kubernetes resources 種類，配置叢集的 HTTP 反向代理，將多個網頁服務集中提供外界存取。} 為 Service 的網頁服務設立反向代理至公網公開等。多個 resources 使得應用部屬有一定的複雜程度，Helm 可以提供更高層級、以應用為中心的單一設定界面，藉此簡化 Kubernetes 的使用。
 
-Helm 用來產生 Kubernetes resources 的模板稱為 Helm Chart，Helm Charts 會集中在 Helm Repository 裡提供使用，Helm Chart 的模板參數稱為 Helm Values，由 Helm 安裝起來的一套應用稱為 Helm Release。透過模板產生的 resources 定義除了套用到 Kubernetes 上之外，Release 會對 resources 額外進行版本紀錄，用以實做更新、回滾、解除安裝等操作。Release 的版本追蹤資訊通常以 Secrets\footnote{Secret: Kubernetes resources 種類，提供資料儲存，本身並不帶有任何功能。} 的形式儲存在叢集內。
+Helm 用來產生 Kubernetes resources 的模板稱為 Helm Chart，Helm Charts 會集中在 Helm Repository 裡提供使用，Helm Chart 的模板參數稱為 Helm Values，由 Helm 安裝起來的一套應用稱為 Helm Release。透過模板產生的 resources 定義除了套用到 Kubernetes 上之外，Release 會對 resources 額外進行版本紀錄，用以實做更新、回滾、解除安裝等操作。Release 的版本追蹤資訊通常以 Secrets 的形式儲存在叢集內。
 
 \begin{figure}[htb]
     \centering

@@ 67,6 67,7 @@ CSKloud 達成一代願景中的開放使用者直接存取 Kubernetes API，使
 網頁界面設計以單一 Kubernetes namespace 為主軸，符合 CSKloud 對使用者提供獨立 namespace 使用的場景。網頁的導覽透過頁面左方的導覽列達成，由此存取各個子功能，並且顯示目前所操作的 namespace。在 Sparkles 上，namespace 可由可搜尋的下拉式選單選擇，在 CSKloud 上，則是固定為使用者對應的 namespace 而停用選單，保留在界面上是為了往後開發出使用者群組功能後，切換至群組所對應的 namespace 使用。
 
 \subsection{Pods 頁面與 Web Terminal 功能實做}
+\label{sec:web-terminal}
 
 \begin{figure}[htb]
     \centering


@@ 78,6 79,7 @@ CSKloud 達成一代願景中的開放使用者直接存取 Kubernetes API，使
     \centering
     \includegraphics[width=\textwidth]{assets/kubectl-pods.png}
     \caption{kubectl 表格式列舉 Pods}
+    \label{fig:kubectl-get-pods}
 \end{figure}
 
 Pods 作為 Kubernetes 中的重要角色之一，表示叢集上運行的容器組合，我們特別為其提供了特製一覽頁面，也展示了網頁在資料呈現與互動上的顯著優於 kubectl 的 CLI 界面。網頁界面可以很容易的繪製較複雜的表格結構，也可以透過顏色幫助使用者快速的分辨異同。同時也能夠在資料上進一步的提供互動，例如點擊容器的 image 連結會導向至相關的資訊頁面，也可以針對項目顯示功能按鈕。


@@ 142,7 144,7 @@ Helm Release 一般的儲存格式需要經過 Base64\footnote{Base64: 一個編
 
 \begin{figure}[htb]
     \centering
-    \includegraphics[width=\textwidth]{assets/web-quotas.png}
+    \includegraphics[width=0.75\textwidth]{assets/web-quotas.png}
     \caption{CSKloud V3 網頁界面 Quotas 頁面}
 \end{figure}
 


@@ 151,9 153,24 @@ Helm Release 一般的儲存格式需要經過 Base64\footnote{Base64: 一個編
 在實做上，由於 ResourceQuota 只帶有配額與佔用總量資訊，須以程式邏輯另外獲取相關取用單位資訊才能自行判斷細項。另外，圓餅圖的繪製透過 Chart.js 開源函式庫實做。
 
 \subsection{Tokens 管理}
+\label{sec:tokens-mgmt}
+
+CSKloud 開放使用者直接存取 API，並且提供 kubectl 連線設定檔。因為叢集本身使用 OIDC 驗證方式，客戶端需要有相關 OIDC 流程邏輯，在網頁界面我們可以直接實做，而對於 kubectl 的場景，我們則是使用 kubelogin 擴充程式，在 kubectl 發出 Kubernetes API 請求時，kubelogin 會檢查是否持有有效的 token，並且在有必要時執行 OIDC 流程。OIDC 需要透過瀏覽器進行網頁登入，導致這個驗證方式雖然在使用者的互動使用時可行且較為安全，在自動化場景卻相當不方便。
+
+對此，我們採用 ServiceAccount tokens 彌補對自動化場景的不足。Tokens 管理頁面幫助使用者設定一個具有當下 namespace 權限的 ServiceAccount，再經由此 ServiceAccount，簽發綁定 Secret 的 token。使用者在簽發 token 時需指定效期，並且可以紀錄相關的用途筆記，存放在對應的 Secret 內。這些 Secrets 使得網頁界面可以紀錄簽發的 tokens，同時作為撤銷 tokens 的手段。
 
 \subsection{Resource Explorer}
 
+% TODO
+
 \subsection{kubectl shell 功能}
 
+隨著 Kubernetes 的更迭，即使我們盡力擴增網頁界面對應的功能，難免還是會有跟不上的時候。即使是現在，雖然我們已經實做了通用型的 Resource Explorer，仍然有少數 Kubernetes 功能無法直接透過網頁界面使用。對此，我們提供一個逃生口 (escape hatch)：在網頁界面直接使用 kubectl 指令。雖然使用者可以自行安裝設定 kubectl，在網頁界面直接提供這個功能還是有免安裝、隨時帶著走的優勢。
+
+實做這個功能有兩個可行方向：使用 WebAssembly 將 kubectl 移植到瀏覽器，或者在叢集內執行 kubectl。前者實際上除了移植 kubectl 指令外，還需提供一個 shell 環境以便使用，在需將環境內各種工具一一移植的前提下，容易產生缺漏使用者想要的項目的窘境，開發成本相當高，於是我們選擇了後者。
+
+kubectl shell 頁面類似於 \ref{sec:tokens-mgmt} Tokens 管理頁面，都會先產生一個具有當下 namespace 權限的 ServiceAccount，但取用的方式不同。接著會採用 Kubernetes 設計上將 ServiceAccount 對 Pod 做的特殊整合，創立一個使用該 ServiceAccount 的 Pod 時，Kubernetes 會自動簽發綁定此 Pod 的 token，並且將 token 與相關連線資訊放置至 Pod 內容器的檔案系統中。容器內具備的 kubectl 指令會自動採用檔案系統內的這些資訊進行連線。再來只須重複利用 \ref{sec:web-terminal} 所述的虛擬終端機連線機制，便可以讓使用者操作容器內的 kubectl 指令。
+
+這個方式雖然因為在叢集內執行容器，會佔用到使用者的資源配額，但實際此場景預期的資源使用極小，對於使用者權益的影響不大。運作機制主要又是基於其他既有的功能做組合，實際開發成本極低，卻十分有效。圖 \ref{fig:kubectl-get-pods} 即是來自於此功能。
+
 \subsection{Node Metrics 視覺化}