1 files changed, 7 insertions(+), 3 deletions(-)

M Sections/3.RelatedWorks.tex

@@ 7,18 7,22 @@
 
 先前系計中已經有意識到基於容器的網頁服務代管平台需求，發展出一套雛型系統，並且歷經兩代變革，分別為 CScloud\cite{cskloud} 與 CScloud with PEKOS (Policy-Enforced Kubernetes OAuth System)\cite{pekos}，本文以「一代」與「二代」代稱。雖然發展已久，但實做仍不完全，並未上線開放使用，在架構規劃也有部份缺點。以下簡單帶過其歷史沿革，並以二代為主進行介紹。
 
-一代系統確立了對平台的大致規劃：以 Kubernetes 提供基於容器的網頁代管服務、以 Kubernetes Namespace 在單一叢集下實施多租戶設計、串接 Kubernetes 內建資源配額機制。作者實做了透過根據由 LDAP 獲取的使用者資訊，為使用者設立 Namespace、資源配額以及以 RBAC 控管使用，並提供對平台網頁界面的設計稿，提出以 Helm 簡化使用方式的想法。在使用者驗證上，作者規劃以平台網頁界面透過串接系計中的身份驗證系統，再由網頁界面創立 token 以進行 Kubernetes API 驗證的使用流程。使用者可以根據該 token 自行存取 Kubernetes API，或者直接使用平台網頁界面存取部份功能。但由於作為身份驗證手段的網頁界面尚未實做，使用者無法進行任何操作，系統無法使用待進一步開發。另外作者指出設計上尚缺乏域名使用權的管控機制。
+一代系統確立了對平台的大致規劃：以 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 邏輯，同時也以此實做域名使用權管控機制。二代系統雖然已經可以運作，具有一定的基本功能，卻因為實做皆以概念驗證的角度撰寫，品質並不適合開放使用，導致系計中普遍對系統有安全性疑慮，並未實際上線。
 
-在實做方面，為了簡化同時避免使用 LDAP、OIDC 兩個協定在類似的場景，二代去除了一代使用自訂 Kubernetes resources 種類實做的 LDAP 使用者開通功能，取而代之的是由網頁界面本身，在使用者首次登入時進行相關的開通。另外安裝少數特定軟體的功能實質是使用 Helm 實做，但網頁界面只提供極少數的 Charts 開放使用，並由程式邏輯產生其 Values 設定，使用者無法對安裝設定（例如資源配置等）做任何修改。由類似的方式可以將功能推廣至其他應用的安裝，以達成一代規劃藉由 Helm 簡化系統使用的願景，但需要人力為每個應用逐一撰寫產生 Values 的邏輯，過於勞力密集且十分缺乏彈性，並且尚未實做更新、回滾等功能。在部屬單一網頁服務的部份，則是採用內建的 resources 模板再針對特定欄位提供表單客製化，因此成果也容易顯的相當侷限，以這個角度設計容易帶有過多的假設，例如假定只須一個容器、假定容器提供服務的 HTTP port 等，並且沒有顧慮到如安裝資料庫等網頁服務本體外的基礎建設場景。
-
 \begin{figure}[htb]
     \centering
     \includegraphics{assets/CScloudV2.png}
     \caption{CScloud with PEKOS 實做架構簡易示意圖}
 \end{figure}
 
+在實做方面，為了簡化同時避免使用 LDAP、OIDC 兩個協定在類似的場景，二代去除了一代使用自訂 Kubernetes resources 種類實做的 LDAP 使用者開通功能，取而代之的是由網頁界面本身，在使用者首次登入時進行相關的開通，而開通後的操作皆由使用者對應的身份操作 Kubernetes。
+
+對於安裝少數特定軟體的功能實質是使用 Helm 實做，但網頁界面只提供極少數的 Charts 開放使用，並由程式邏輯產生其 Values 設定，使用者無法對安裝設定（例如資源配置等）做任何修改。由類似的方式可以將功能推廣至其他應用的安裝，以達成一代規劃藉由 Helm 簡化系統使用的願景，但需要人力為每個應用逐一撰寫產生 Values 的邏輯，過於勞力密集且十分缺乏彈性，並且尚未實做更新、回滾等功能。
+
+在部屬單一網頁服務的部份，則是先設計一個部屬設定客製化表單，再透過填入一個 resources 模板達成，由開發者自行設想的使用需求出發，因此成果也容易顯的相當侷限。以這個角度設計容易帶有過多的假設，例如：假定只須一個容器、假定容器提供服務的 HTTP port number 等，並且沒有顧慮到如安裝資料庫等網頁服務本體外的基礎建設場景。
+
 二代的網頁界面實做使用單體式的傳統架構，包含使用者開通的功能，全部由單一一個網頁後端伺服器負責。使用者開通是藉由以管理者身份存取 Kubernetes API 達成，管理者的驗證相關資訊必須在存放在網頁伺服器上，單體式的架構使得有過大的攻擊面，其他功能的程式碼紕漏可能會導致管理者金鑰外洩，使攻擊者得以藉此控制整座叢集。在安裝特定軟體的部份，因為使用的程式語言與 Helm 不符，採取以執行指令操作 Helm CLI 達成。這種方式雖然易於實做，但也容易產生使用者能夠注入其他指令或是預期外的參數等漏洞。
 
 % 大概留到設計那邊, 帶出 from KaaS 立足點出發的不同