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

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

@@ 37,7 37,7 @@ Kubernetes resources 的種類帶給 resources 既定的語意和格式，例如
 
 Kubernetes 的身份驗證策略採用完全以驗證手段提供身份資訊的方式，包含身份名稱以及所在的群組等。Kubernetes 原則上並不存放身份對應的資料，這樣的設計使得伺服器負擔減少，同時有架構單純、易於除錯等優勢，但根據手段不同，可能會使得修改相關資訊（如修改所在的群組）變得不便。其中面向使用者的驗證手段主要有：X.509 憑證、authenticating proxy、static tokens、webhook tokens、ServiceAccount tokens 與 OpenID Connect tokens。
 
-Kubernetes 中的 X.509 憑證即為 TLS 客戶端憑證 (client certificate)，在 TLS 的驗證模型下，除了伺服器端需要提供憑證確保伺服器端的真實性以外，客戶端也可以提供憑證，使伺服器端得以驗證客戶端的身份。此機制近期又以 mutual TLS (mTLS) 的名稱流行，強調雙方都可以驗證彼此的身份。Kubernetes 將身份名稱與所在群組存放在客戶端憑證的 Subject 屬性內，並且要求憑證來自特定（通常直接由叢集管理）的簽發單位 (certificate authority, CA)，藉此確保資訊的真實性。雖然 X.509 標準有定義憑證的撤銷機制，但目前 Kubernetes 並沒有相關實做，導致只能利用簽發短期限的憑證，達到金鑰洩漏的減災，同樣原因也使得這個方法不易修改群組資訊。由於客戶端憑證較不方便使用，尤其需要透過頻繁換發短期限憑證達到安全性，相關自動化成本較高，除了叢集內部元件的身份驗證外，較不常用於使用者端，多見於非正式環境，或是另外嚴謹保存作為管理員的備用手段。
+Kubernetes 中的 X.509 憑證即為 TLS 客戶端憑證 (client certificate)，在 TLS 的驗證模型下，除了伺服器端需要提供憑證確保伺服器端的真實性以外，客戶端也可以提供憑證，使伺服器端得以驗證客戶端的身份。此機制近期又以 mutual TLS (mTLS) 的名稱流行，強調雙方都可以驗證彼此的身份。Kubernetes 將身份名稱與所在群組存放在客戶端憑證的 Subject 屬性內，並且要求憑證來自特定（通常直接由叢集管理）的簽發單位 (certificate authority, CA)，藉此確保資訊的真實性。雖然 X.509 標準有定義憑證的撤銷機制，但目前 Kubernetes 並沒有相關實做，導致只能利用簽發短期限的憑證，達到金鑰洩漏的減災，同樣原因也使得這個方法不易修改群組資訊。由於客戶端憑證較不方便使用，尤其需要透過頻繁換發短期限憑證達到安全性，相關自動化成本較高，除了叢集內部元件的身份驗證外，較不常用於使用者端，多見於非正式環境，或是另外嚴謹保存作為管理者的備用手段。
 
 Authenticating proxy 透過在 Kubernetes API 之前加一層 proxy 伺服器進行驗證邏輯。Proxy 在將請求轉發給 Kubernetes API 時會加上相關 HTTP headers 以表明使用者身份，而 proxy 本身對使用者的認證方式並沒有限制。這個方法等同於將驗證邏輯直接抽出另外自行實做，開發成本較高，並且需自行注意如撤銷等機制的是否完善。
 

@@ 56,6 56,7 @@ CSKloud 達成一代願景中的開放使用者直接存取 Kubernetes API，使
 \end{onehalfspacing}
 
 \subsection{PodSecurity}
+\label{sec:PodSecurity}
 
 容器一般被視為一個與宿主端 (host) 隔離的環境，但由於容器具有自成一體 (self-contained) 的特性，能夠大幅簡化部屬管理，在 Kubernetes 的場合更可以統一管理叢集內部各節點的容器，因此容器也常被用來部屬與宿主端有關的底層基礎設施。此場景需要局部地關閉容器的隔離功能，來達成如管理宿主端網路環境等操作。對此，Kubernetes 在 Pod 的 \verb|spec| 欄位設計多個開關，提供解除部份隔離機制的途徑。
 


@@ 81,6 82,7 @@ CSKloud 達成一代願景中的開放使用者直接存取 Kubernetes API，使
 在容器生態下，images 主要可分為公開存取以及私人的兩種。下載公開存取的 images 不須經過身份驗證，而私人的 images 則是需要。由於 \verb|IfNotPresent| 與 \verb|Never| 在節點已經存有指定 image 時，不會進行任何更新檢查，因此也不需進行身份驗證，如此在共用叢集的狀況下，便形成了一個可能用來存取他人遺留在節點上的私人 images 的途徑。對此，我們採用 \verb|AlwaysPullImages| 將下載策略一律複寫為 \verb|Always|。
 
 \subsection{CEL}
+\label{sec:CEL}
 
 對於防止使用者在 control plane 上運行容器，\ref{sec:PodTolerationRestriction} \verb|PodTolerationRestriction| 仍然不足。預設在 control plane 上的 taint 只有防止排程，使用者實際上可以繞過排程直接指定節點。一個解決方法是修改 control plane 上的 taint，改為防止執行而非單純防止排程，但由於這個 taint 由 Kubernetes 安裝工具提供，實際上已被廣泛使用，修改容易造成管理上的負擔，若欠缺注意更有可能造成部屬叢集元件時意外安排到 worker nodes 上，間接影響叢集服務品質。於是我們採取另外撰寫邏輯，防止使用者繞過排程。這同時也有附加的優勢：使用者提交的工作負載一律會經過平台的排程機制，使資源的充分、平均利用更有保障。
 


@@ 111,10 113,18 @@ CSKloud 達成一代願景中的開放使用者直接存取 Kubernetes API，使
 
 實際上以 \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 變可以徹底清除此使用者的所作所為。
+對於管理需求，我們在 admission control 實做保留了彈性，若操作者為管理者即不加以限制。管理者可以自行創立代表他人的 User，為其修改身份組，提供人工處理政策上例外的空間。另外，由 User 所產生的每個 resource 皆會採用 Kubernetes 的 \verb|ownerReferences| 機制。\verb|ownerReferences| 表現了一個 resource 被一個 owner resource 所管轄，當 owner resource 被刪除時，Kubernetes 的回收機制也會一併刪除此 resource。在我們的場景，由於使用者的資料皆為於個人專屬的 Namespace 底下，而 User 又為此 Namespace 的 owner resource，於是當使用者行為極端異常，管理者需要對其制裁時，只須刪除其 User 變可以徹底清除此使用者的所作所為。
 
 在實做方面，User 種類的定義以及 controller 邏輯採取 kubebuilder 框架實做。kubebuilder 採用 Go 程式語言，以及 \verb|sig.k8s.io/controller-runtime| 函式庫開發，提供由 Go 語言的資料結構定義輔以註解擴充，搭配程式碼生成技術實現 Kubernetes resource 種類的定義，並且提供實做 controller 時所需的監控 resources 變更等基本邏輯。另外，\verb|sig.k8s.io/controller-runtime| 亦具備 \verb|envtest| 測試框架，自動化運行 \verb|kube-apiserver| 等元件，在不需要架設完整叢集的前提下，提供 controller 較為完整的測試環境。
 
+\subsection{Namespace}
+
+為了避免命名與叢集上既有、負責叢集本身運行的 Namespaces 衝突，我們將使用者的 Namespace 命名為 \verb|u-| 前綴加上系計中帳號名稱（即相關 User resource 的名稱）。
+
+在創立 Namespace 時，根據個別的 admission controllers 設計，需要在 \verb|labels| 或 \verb|annotations| 上加註政策。\verb|labels| 與 \verb|annotations| 皆是 Kubernetes resources 共通的 key-value 標記，常用以輔助管理辨識，或是以較高的彈性提供次要的功能，其中 \verb|labels| 在透過 Kubernetes API 列舉時可以用來作為條件過濾 resources，但同時能夠儲存的內容也具有相關限制。需要設定的有 \ref{sec:PodSecurity} PodSecurity、\ref{sec:PodTolerationRestriction} PodTolerationRestriction 與 \ref{sec:CEL} 以 CEL 實做的域名使用權管控。為了方便管理者透過過濾進行清查，域名管控我們設計以 \verb|labels| 設定白名單，一個域名一條 label。平台預設開放如帳號名稱加上 \verb|.u.cloud.cs.nycu.edu.tw| 後綴的域名供使用者使用。
+
+Namespace 上 \verb|u-| 以及平台提供域名中 \verb|u.| 的命名切分設計使得平台可以進一步擴充，除了以使用者為單位以外，未來可以增加其他種類的命名切分，提供以如實驗室或課程為單位的服務。
+
 \section{網頁界面實做}
 
 進一步對網頁界面的需求分析，可以將網頁界面切分為兩大塊：支援 Helm 的通用 Kubernetes 網頁型客戶端，以及 CSKloud 特定的部份，包含權限開通元件的整合以及 CSKloud 平台面向使用者的文件等。其中 Kubernetes 客戶端很容易的就可以利用於其他場景，我們採取 open core 的策略，將其 Kubernetes 客戶端開放原始碼，以 MIT 授權條款\footnote{MIT license: 一個在網頁技術場域廣受歡迎的寬鬆型開放原始碼條款。}釋出，命名為 Sparkles\footnote{Sparkles 釋出於 \url{https://github.com/xdavidwu/sparkles} 。}，回饋於社會，使得非平台使用者也能受益，同時可以也利用開放原始碼社群的力量來茁壯平台的發展。