5 files changed, 7 insertions(+), 7 deletions(-)

M Sections/0.2.Abstract_chinese.tex
M Sections/0.3.Abstract.tex
M Sections/2.Backgrounds.tex
M Sections/3.RelatedWorks.tex
M Sections/4.Architecture.tex

@@ 23,7 23,7 @@
 
 國立陽明交通大學資工系資訊中心基於輔助系上發展的立場，同時為了減輕教授與實驗室架設伺服器上的軟硬體負擔，希望提供一個可以快速建置動態內容網頁的代管平台。考量到平台通用性與運行成本，在此方面容器技術具有相當優勢，其中又以 Kubernetes 最為代表，具備各式高擴展性功能，並提供一標準 API 界面，使應用部屬流程更為廣泛通用。
 
-本篇論文將探討如何基於 Kubernetes Namespace 設計多租戶架構，建構出具有資源配額的 Kubernetes-as-a-Service (KaaS) 平台，充分運用 Kubernetes 內建及自訂 admission controllers 邏輯以改善其安全性；同時為其設計易用的網頁界面，並將網頁界面的核心功能以通用型 Kubernetes 客戶端開放原始碼釋出。
+本篇論文將探討如何基於 Kubernetes Namespace 設計多租戶架構，建構出具有資源配額的 Kubernetes-as-a-Service (KaaS) 平台，充分運用 Kubernetes 內建及自訂 admission control 邏輯以改善其安全性；同時為其設計易用的網頁界面，並將網頁界面的核心功能以通用型 Kubernetes 客戶端開放原始碼釋出。
 
 \vspace{1cm}
 

@@ 30,7 30,7 @@
   
 For the prosperity of the department, also to reduce the software and hardware burden of running web servers for professors and labs, Information Technology Center, Department of Computer Science, National Yang Ming Chiao Tung University demands a hosted platform for quickly setting up dynamic content websites. Considering generalization and operation cost of the platform, container technologies are especially attractive, of which Kubernetes is the most iconic one designed with high-scalability in mind. Kubernetes also provides a standard API, making flows of application deployment easily adoptable and widely reusable.
 
-This thesis dives into how to design a multi-tenancy architecture based on Kubernetes namespaces, how to build a Kubernetes-as-a-Service (KaaS) with quotas, and how to utilize admission controllers, both built-in and custom, to improve its security. It also discusses about how to design a easy-to-use web interface for such platform, which core is also released as an open source generic Kubernetes client.
+This thesis dives into how to design a multi-tenancy architecture based on Kubernetes namespaces, how to build a Kubernetes-as-a-Service (KaaS) with quotas, and how to utilize both built-in and custom admission control logic to improve its security. It also discusses about how to design a easy-to-use web interface for such platform, which core is also released as an open source generic Kubernetes client.
 
 
 \vspace{1cm}

@@ 53,7 53,7 @@ OpenID Connect (OIDC) 則是一個基於 OAuth 框架衍生的身份驗證協定
 
 Kubernetes 主要透過兩個機制達成使用者的存取控制，其一是 RBAC (Role-based access control)。RBAC 可以根據 resources 的種類、所在的 Namespace 或是特定的 resource 實例授予使用者對其進行操作的權力，包含創立、刪除、更新、獲取、列舉等，不同類型的操作可以分別授予。
 
-另一個機制為 admission controllers，在 RBAC 後執行，可以根據被創立或更新的 resources 內容進行控制，又分為 mutating 與 validating 兩種。Mutating admission controllers 可以修改 resources 內容，常用於對 resources spec 中的特定欄位賦予預設值。以 mutating admission controllers 賦予預設值的方法，比起在實做 resources 的 controller 定義預設行為，以使用者的立場更為明確，使用者可以觀察創建或修改後的 resource 內容得知其行為，對於平台提供者，也可以透過這個機制實做平台特定的預設值。Validating admission controllers 則無法修改 resources 內容，只能做出允許或拒絕操作的決策，為了能夠驗證最終的 resources 內容，編排在 mutating admission controllers 後執行，常用於執行特定設定上的政策。由於 Kubernetes 功能上的廣泛，不適合將每個功能都規劃成獨立的 resources 種類，用 RBAC 針對 resources 種類進行存取控制有時會顯得不足，admission controllers 便補足了這方面的彈性。
+另一個機制為 admission control，在 RBAC 後執行，可以根據被創立或更新的 resources 內容進行控制。實做該邏輯的 admission controllers 主要又分為 mutating 與 validating 兩種。Mutating admission controllers 可以修改 resources 內容，常用於對 resources spec 中的特定欄位賦予預設值。以 mutating admission controllers 賦予預設值的方法，比起在實做 resources 的 controller 定義預設行為，以使用者的立場更為明確，使用者可以觀察創建或修改後的 resource 內容得知其行為，對於平台提供者，也可以透過這個機制實做平台特定的預設值。Validating admission controllers 則無法修改 resources 內容，只能做出允許或拒絕操作的決策，為了能夠驗證最終的 resources 內容，編排在 mutating admission controllers 後執行，常用於執行特定設定上的政策。由於 Kubernetes 功能上的廣泛，不適合將每個功能都規劃成獨立的 resources 種類，用 RBAC 針對 resources 種類進行存取控制有時會顯得不足，admission control 便補足了這方面的彈性。
 
 Kubernetes 內建許多 admission controllers，其中一些用來實做基本功能並預設啟用，例如資源配額的部份邏輯即是以這個機制實做。另外也有些預設停用的 admission controllers，提供給管理者進行平台加固或者調整行為使用。
 

@@ 9,7 9,7 @@
 
 一代系統確立了對平台的大致規劃：以 Kubernetes 提供基於容器的網頁代管服務、以 Kubernetes Namespace 在單一叢集下實施多租戶設計、串接 Kubernetes 內建資源配額機制。作者經由自訂 Kubernetes resources，實做了透過根據由 LDAP\footnote{Lightweight Directory Access Protocol，用於提供身份資訊存取服務的協定。} 獲取的使用者資訊，為使用者設立 Namespace、資源配額以及以 RBAC 控管使用的機制。另外提供對平台網頁界面的設計稿，提出以 Helm 簡化使用方式的想法。在使用者驗證上，作者規劃以平台網頁界面透過串接系計中的身份驗證系統，再由網頁界面創立 token 以進行 Kubernetes API 驗證的使用流程。使用者可以根據該 token 自行存取 Kubernetes API，或者直接使用平台網頁界面存取部份功能。但由於作為身份驗證手段的網頁界面尚未實做，使用者無法進行任何操作，系統無法使用待進一步開發。另外作者指出設計上尚缺乏域名使用權的管控機制。
 
-二代系統沿襲了一代對於多租戶與資源配額的設計，另外將身份驗證以 OIDC 實做，發展出可運作的基本網頁界面，並實做部屬單一網頁服務，以及安裝少數特定軟體的功能，但並未如一代規劃開放使用者直接存取 Kubernetes API。對於 Kubernetes 叢集本身，二代系統指出在此基於 Namespace 的多租戶設計下，Kubernetes RBAC 驗證對於限制使用者的行為並不足夠，並且導入 admission controllers 作為加固手段，以 Open Policy Agent 框架透過 webhooks 自行實做 admission controllers 邏輯，同時也以此實做域名使用權管控機制。二代系統雖然已經可以運作，具有一定的基本功能，卻因為實做皆以概念驗證的角度撰寫，品質並不適合開放使用，導致系計中普遍對系統有安全性疑慮，並未實際上線。
+二代系統沿襲了一代對於多租戶與資源配額的設計，另外將身份驗證以 OIDC 實做，發展出可運作的基本網頁界面，並實做部屬單一網頁服務，以及安裝少數特定軟體的功能，但並未如一代規劃開放使用者直接存取 Kubernetes API。對於 Kubernetes 叢集本身，二代系統指出在此基於 Namespace 的多租戶設計下，Kubernetes RBAC 驗證對於限制使用者的行為並不足夠，並且導入 admission control 作為加固手段，以 Open Policy Agent 框架透過 webhooks 自行實做 admission control 邏輯，同時也以此實做域名使用權管控機制。二代系統雖然已經可以運作，具有一定的基本功能，卻因為實做皆以概念驗證的角度撰寫，品質並不適合開放使用，導致系計中普遍對系統有安全性疑慮，並未實際上線。
 
 \begin{figure}[htb]
     \centering

@@ 19,7 19,7 @@
 
 \subsection{安全性}
 
-二代架構設計將需要高權限、低使用量的使用者開通元件以及低權限、高使用量的使用者互動界面實做為單一一個單體式網頁服務，不同權限層級的操作間欠缺隔離手段。另外在實做上也欠缺資訊安全意識，其根據使用者操作在伺服器端呼叫 Helm CLI 的方式也容易產生漏洞。完全仰賴自行定義的 admission controllers 邏輯進行 Kubernetes 叢集本身的加固，由於 Kubernetes API 的複雜性，也容易由於未充分理解而有所缺失。
+二代架構設計將需要高權限、低使用量的使用者開通元件以及低權限、高使用量的使用者互動界面實做為單一一個單體式網頁服務，不同權限層級的操作間欠缺隔離手段。另外在實做上也欠缺資訊安全意識，其根據使用者操作在伺服器端呼叫 Helm CLI 的方式也容易產生漏洞。完全仰賴自行定義的 admission control 邏輯進行 Kubernetes 叢集本身的加固，由於 Kubernetes API 的複雜性，也容易由於未充分理解而有所缺失。
 
 以系計中在運作方面上的特色而言，由於主力開發人力來自於碩士班研究生以及部份學士班的打工，人員更迭極為快速，並且提供的服務眾多，難以分配專屬人力，一人經常身兼多職維護多個產品，歷史上僅有少數人能夠深入了解既有服務實做細節。面對這樣的場景，以及考量到本平台的重要性，由初步規劃即必須嚴謹考量資訊安全，從架構起手進行防禦，以免在日後他人迭代維護時產生紕漏。
 


@@ 37,7 37,7 @@
 
 針對這些需求，我們提出新的架構，稱為 CSKloud V3（以下簡寫 CSKloud）。我們將權限開通元件拆分，改採類似於一代的方式，透過自訂 Kubernetes resource 類型撰寫。一代的開通流程仰賴於管理者手動觸發，CSKloud 則是採取更自動的流程。透過 Kubernetes 對於身份驗證的設計，OIDC 驗證前不須針對新使用者進行設定，即可進行身份驗證，我們設計賦予所有使用者創立此自訂 resource 的權限，在網頁界面首次登入時自動創立，作為開通流程的觸發機制。同時權限開通元件本身並不會自行查詢使用者身份資訊，而是透過創立者的驗證資訊判斷。
 
-對於叢集本身的加固，二代採用 webhooks 的形式自行定義 admission controllers，而 CSKloud 改以 Kubernetes 本身內建的 admission controllers 為主，有利於確保相關防禦的完備性，並且隨著 Kubernetes 的更迭，內建的 admission controllers 也會有對應的邏輯更新，大幅減少後續在維護上的負擔，同時其行為也更為通用，更容易對使用者描述，使得使用者可以對平台所提供的功能有更明確的認知。整個系統難免還是有內建 admission controllers 無法涵蓋的其餘需求，例如域名使用權的管控，這部份 CSKloud 以 CEL 重新實做取代 webhooks，以達到更好的效能及更低的運作成本。
+對於叢集本身的加固，二代採用 webhooks 的形式自行定義 admission control，而 CSKloud 改以 Kubernetes 本身內建的 admission controllers 為主，有利於確保相關防禦的完備性，並且隨著 Kubernetes 的更迭，內建的 admission controllers 也會有對應的邏輯更新，大幅減少後續在維護上的負擔，同時其行為也更為通用，更容易對使用者描述，使得使用者可以對平台所提供的功能有更明確的認知。整個系統難免還是有內建 admission controllers 無法涵蓋的其餘需求，例如域名使用權的管控，這部份 CSKloud 以 CEL 重新實做取代 webhooks，以達到更好的效能及更低的運作成本。
 
 CSKloud 達成一代願景中的開放使用者直接存取 Kubernetes API，使用者可以透過標準 Kubernetes 客戶端（如 kubectl\footnote{kubectl: Kubernetes 官方提供的 CLI （指令列界面）型客戶端。}）存取叢集，但仍然提供一個網頁界面。除了用以觸發前述的權限開通流程，這個網頁界面同時具備作為 Kubernetes 的通用型網頁界面的功能，由 Kubernetes 的角度出發設計，用意主要在輔助與簡化 Kubernetes 的使用，以及提供 kubectl 所缺乏的配額視覺化等在 CLI 場景難以實做的功能。
 


@@ 45,7 45,7 @@ CSKloud 達成一代願景中的開放使用者直接存取 Kubernetes API，使
 
 \section{叢集加固實做}
 
-由於 Kubernetes 的功能廣泛，有許多的功能具有較大的權限，間接具備控制整座叢集的能力，在一個共有的平台下，有部屬不受信任的工作負載的可能，使用 admission controllers 限制功能是必要的，對此我們以引入 Kubernetes 內建的 admission controllers 為主，輔以 CEL 進一步實做缺乏的邏輯。我們主要引入下列內建的 admission controllers：
+由於 Kubernetes 的功能廣泛，有許多的功能具有較大的權限，間接具備控制整座叢集的能力，在一個共有的平台下，有部屬不受信任的工作負載的可能，使用 admission control 限制功能是必要的，對此我們以引入 Kubernetes 內建的 admission controllers 為主，輔以 CEL 進一步實做缺乏的邏輯。我們主要引入下列內建的 admission controllers：
 
 \begin{onehalfspacing}
 \begin{itemize}