9 files changed, 46 insertions(+), 0 deletions(-)

M Sections/2.Backgrounds.tex
M Sections/4.Architecture.tex
A assets/authn-oidc-tokens.png
A assets/authn-proxy.png
A assets/authn-sa-tokens.png
A assets/authn-static-tokens.png
A assets/authn-webhook-tokens.png
A assets/authn-x509.png
A assets/kubernetes-watch.png

@@ 35,6 35,46 @@ Kubernetes resources 的種類形成了既定的語意和格式，例如：Pod 
 
 Kubernetes 提供多個身份驗證手段，可搭配混合使用，在設計上盡量單獨以驗證手段提供完整身份資訊，包含身份名稱以及所在的群組等，叢集本身以不存放身份對應的資料為原則。這樣的設計使得伺服器負擔減少，同時具有架構單純、易於除錯等優勢，但根據手段不同，可能會使得更動身份資訊（如修改所在的群組）顯得不便。常見的驗證手段主要有：X.509 憑證、authenticating proxy、static tokens、webhook tokens、ServiceAccount tokens 與 OpenID Connect tokens。
 
+\begin{figure}[htb]
+    \centering
+    \begin{subfigure}{0.31\textwidth}
+        \centering
+        \includegraphics[width=\textwidth]{assets/authn-x509.png}
+        \caption{X.509 憑證}
+    \end{subfigure}
+    ~
+    \begin{subfigure}{0.31\textwidth}
+        \centering
+        \includegraphics[width=\textwidth]{assets/authn-proxy.png}
+        \caption{Authenticating proxy}
+    \end{subfigure}
+    ~
+    \begin{subfigure}{0.31\textwidth}
+        \centering
+        \includegraphics[width=\textwidth]{assets/authn-static-tokens.png}
+        \caption{Static tokens}
+    \end{subfigure}
+    \begin{subfigure}{0.31\textwidth}
+        \centering
+        \includegraphics[width=\textwidth]{assets/authn-webhook-tokens.png}
+        \caption{Webhook tokens}
+    \end{subfigure}
+    ~
+    \begin{subfigure}{0.31\textwidth}
+        \centering
+        \includegraphics[width=\textwidth]{assets/authn-sa-tokens.png}
+        \caption{ServiceAccount tokens}
+    \end{subfigure}
+    ~
+    \begin{subfigure}{0.31\textwidth}
+        \centering
+        \vspace{1em}
+        \includegraphics[width=\textwidth]{assets/authn-oidc-tokens.png}
+        \caption{OpenID Connect tokens}
+    \end{subfigure}
+    \caption{Kubernetes 身份驗證手段簡易示意圖}
+\end{figure}
+
 Kubernetes 中的 X.509 憑證即為 TLS 客戶端憑證 (client certificate)，在 TLS 的驗證模型下，除了伺服器端需要提供憑證證明本身的真實性以外，客戶端也可以提供憑證，使伺服器端得以驗證客戶端的身份 (client certificate authentication, CCA)。此機制近期又以 mutual TLS (mTLS) 的名稱流行，強調雙方都可以驗證彼此的身份。Kubernetes 將身份名稱與所在群組存放在客戶端憑證的 Subject 屬性內，並且要求憑證來自特定的簽發單位 (certificate authority, CA)，通常直接由叢集管理，藉此確保資訊的真實性。雖然 X.509 標準有定義憑證的撤銷機制\cite{rfc5280}\cite{rfc6960}，但目前 Kubernetes 並沒有相關實做，導致只能利用簽發短效期的憑證，達到金鑰洩漏場景的減災。缺乏撤銷機制也使得這個驗證方法不易修改身份資訊。由於客戶端憑證較不方便使用，尤其需要透過頻繁換發短效期憑證達到安全性，相關自動化成本較高，除了叢集內部元件的身份驗證外，較不常用於使用者端，多見於非正式環境，或是另外嚴謹保存作為管理者的備用手段。
 
 Authenticating proxy 透過在 Kubernetes API 之前加一層代理伺服器進行驗證邏輯。在將請求轉發給 Kubernetes API 時，代理伺服器會加上約定的 HTTP headers 以表達使用者身份。對於代理伺服器驗證使用者的方式並沒有限制。這個方法等同於將驗證邏輯直接抽出另外自行實做，相當富有彈性，但開發成本較高，並且需自行注意撤銷等機制是否完善。

@@ 159,6 159,12 @@ ResourceQuota 所能管控的資源大致有兩種：運算資源以及 resource
 
 網頁界面採用 Vue.js\cite{vue} 框架，以 TypeScript 語言\footnote{TypeScript: 一個轉譯為 JavaScript 的語言，比起 JavaScript 多了型別標示以利開發。}撰寫，使用 Vuetify 做為元件庫。Vuetify 的元件設計採用基於 Google 提出的 Material Design 設計語彙，同時 Kubernetes 也是由 Google 發跡的，在些許程度上，選擇 Vuetify 帶給了 Kubernetes 使用者更契合的親切感。由於界面希望帶有在容器內執行指令的功能，所需的終端機傳統上採用黑底白字配色，為避免其元件顯得突兀，整體界面亦採暗色系設計。在流行上，近期資訊界生產力相關的網頁服務也有逐漸導入暗色系設計的趨勢。
 
+\begin{figure}[htb]
+    \centering
+    \includegraphics{assets/kubernetes-watch.png}
+    \caption{Kubernetes watch 機制示意圖}
+\end{figure}
+
 對於 Kubernetes API 的操作，我們採用由 Kubernetes 提供的 OpenAPI\footnote{OpenAPI: 一種用於描述 RESTful API 行為的框架。}\cite{openapi} 定義檔，透過 openapi-generator\footnote{openapi-generator: 由 OpenAPI 定義檔產生適用於各種不同語言的函式庫的工具。} 自動產生的函式庫輔助開發。在網頁的各個功能，我們皆有採用 Kubernetes 的 watch 機制達到資料的即時更新。Kubernetes 的 watch 是一個特有的 HTTP API 呼叫方法，透過維持長期不中斷的 HTTP response，藉由 HTTP 的 chunked encoding\footnote{Chunked encoding: 一個將內容分塊傳送的 HTTP 編碼機制，常用於串流等持續產生資料的場合\cite{swaminathan2011low}。} 編碼，即時的將一個 resources 列表的內容更新以新增、移除、修改 resource 等事件傳出，並且每個事件帶有一個版本號，如果 HTTP 通訊意外中止，客戶端可以透過這個版本號代表目前對 resources 列表的認知，向 Kubernetes 重發一個 watch 呼叫獲取由該版本後的變更。這個機制也廣泛運用在 Kubernetes 元件內部的溝通。
 
 \begin{figure}[htb]