\chapter{相關研究}
\label{ch:related-works}

本章節敘述系計中對於此議題所發展出的 CScloud Platform-as-a-Service (PaaS) 雛型系統，並分析其架構優劣，作為本研究的基石，另外討論 Kubernetes 上常見的多租戶模型，分析對本研究的適用性。

\section{CScloud}

先前系計中已經有意識到基於容器的網頁服務代管平台需求，發展出一套雛型系統，並且歷經兩代變革，分別為 CScloud\cite{cskloud} 與 CScloud with PEKOS (Policy-Enforced Kubernetes OAuth System)\cite{pekos}，本文以「一代」與「二代」代稱。雖然發展已久，但實作仍不完全，並未上線開放使用，在架構規劃也有部份缺點。以下簡略帶過其歷史沿革，並以二代為主進行介紹。

一代系統確立了對平台的大致規劃：以 Kubernetes 提供基於容器的網頁代管服務、以 Namespace 在單一叢集下實施多租戶設計、串接 Kubernetes 內建資源配額機制。作者經由自訂 Kubernetes resource 種類，實做了根據自 LDAP\footnote{Lightweight Directory Access Protocol，用於提供身份資訊存取服務的協定。} 獲取的使用者資訊，為使用者設立 Namespace、資源配額與以 RBAC 控管使用的機制。另外提供對平台網頁界面的初步設計稿，提出以 Helm 簡化使用方式的想法。在使用者身份驗證上，作者構思了以平台網頁界面串接系計中的身份驗證系統，再於網頁界面上創立 token 以進行 Kubernetes API 驗證的使用流程。使用者可以透過該 token 自行存取 Kubernetes API，或者直接使用平台網頁界面存取部份功能。但由於作為身份驗證手段的網頁界面尚未實做，使用者無法進行任何操作，系統無法使用，有待進一步開發。另外作者指出設計上尚缺乏域名使用權的管控機制。

二代系統沿襲了一代對於多租戶與資源配額的設計，另外將身份驗證以 OIDC 實做，發展出可運作的基本網頁界面，並實做部屬單一網頁服務，以及安裝少數特定軟體的功能，但並未如一代規劃開放使用者直接存取 Kubernetes API。對於叢集本身，二代指出在此基於 Namespace 的多租戶設計下，RBAC 對於限制使用者的行為並不足夠，並且導入 admission control 作為加固手段，以 Open Policy Agent 框架透過 webhooks 自行實做 admission control 邏輯，同時也以此實做域名使用權管控機制。二代系統雖然已經可以運作，具有些許的基本功能，卻因為實作皆以概念驗證的角度撰寫，品質並不適合開放使用，導致系計中內部普遍對系統有安全性疑慮，並未實際上線運行。

\begin{figure}[htb]
    \centering
    \includegraphics[width=\textwidth]{assets/CScloudV2.png}
    \caption{CScloud with PEKOS 實作架構簡易示意圖}
\end{figure}

在實作方面，為了避免同時使用 LDAP、OIDC 兩個協定在類似的場景，二代去除了一代使用自訂 Kubernetes resource 種類實做的 LDAP 使用者開通功能，取而代之的是由網頁界面本身，在使用者首次登入時進行相關的開通，而開通後的互動皆由使用者對應的身份操作 Kubernetes。

二代安裝少數特定軟體的功能實質是使用 Helm 實做，但網頁界面僅提供極少數的 Helm Charts 開放使用，並由程式邏輯產生其 Helm Values 設定，使用者無法對安裝設定（例如資源配置等）做任何修改。由相同的機制可以將功能推廣至其他應用的安裝，以達成一代規劃藉由 Helm 簡化系統使用的願景，但需要人力為每個應用逐一撰寫產生 Values 的邏輯，過於勞力密集且十分缺乏彈性，並且尚未實做更新、回滾等功能。

在部屬單一網頁服務的部份，則是先設計一個部屬設定客製化表單，再透過填入固定的 resources 模板達成，由開發者自行設想的使用需求出發，因此成果也容易顯得相當侷限。以這個角度設計容易忽略部份需求，而帶有過多的假設，例如：假定只須一個容器、假定容器提供服務的 HTTP port number 等，並且無法相容於如安裝資料庫等網頁服務本體外的基礎建設場景。另外，基於模板的概念與 Helm 相似，實作上還有統一簡化的空間。

二代的網頁界面實作採用單體式的傳統架構，包含使用者開通的功能，全部由單一一個網頁後端伺服器負責。使用者開通是藉由管理者身份存取 Kubernetes API 達成，管理者的驗證相關資訊必須在存放在網頁伺服器上，單體式的架構使得這部份有過大的潛在攻擊面，其他功能的程式碼紕漏可能會導致管理者金鑰外洩，使攻擊者得以藉此控制整座叢集。

在安裝特定軟體的方面，因為使用的程式語言 PHP 與 Helm 所採用的 Go 不符，二代採取以執行指令操作伺服器上的 Helm CLI 達成。這種方式雖然易於實做，但也容易產生使用者能夠注入其他指令或是預期外的參數等漏洞，影響到伺服器的安全。

由於 Kubernetes 非同步的設計，狀態更新的推送顯得十分重要，而二代的網頁實作並沒有針對這點設計，而是仰賴於完整的頁面刷新，這也可能造成過度重複執行其餘資料未變更的邏輯運算，間接使得運行成本增加。

\section{Kubernetes 的多租戶模型}

雲端運算的一大要點為集結大量資源，予以集中管理，彈性分配給多個租戶使用以提高運用效率。然而 Kubernetes 因功能的廣泛，以及專注於單一租戶的歷史脈絡，導致實做多租戶有多個不同的方法與隔離程度，其中依照使用場景又常分為軟、硬兩種多租戶層級\cite{k8smultitenancy}。

軟多租戶指的是租戶間擁有一定程度的信任，在租戶間的隔離與安全性上的需求較低，而專注於防止租戶間的操作意外影響，常見於同個公司內部的不同團隊。硬多租戶則是指租戶間無法存在信任，任一租戶都必須視為可能的攻擊者，在設計上必須以隔離、安全性為優先考量，常見於公有服務。本研究欲達成的目標為硬多租戶。

Kubernetes Namespaces 由於只影響 API 上能描述的 resources 相互關係，並不隱含實際工作負載的隔離，常用來實做軟多租戶。然而，透過 admission control 我們仍可為 resource 內容加以把關，確保使用者在其他層面啟用對工作負載的隔離措施，防止在共用叢集的架構下影響其他租戶，彌補 Namespaces 在此方面的不足，以達成硬多租戶的目標。CScloud 即是採用此類方案，但同時帶來的是大量的 admission control 加固開發成本。另外由於 Namespaces 設計上無法管控 cluster-scoped 的 resource 種類，在此方案下租戶無法使用相關功能。

在硬多租戶的議題下，另一個常見許多的手法則是基於叢集的多租戶模型，透過給予每個租戶獨立的叢集，進而免除對叢集內部的大多數加固需求，以高層次架構來看單純許多，並且租戶能夠使用較完整的 Kubernetes 功能。

基於叢集的多租戶需要動態的配置多個獨立叢集與節點，因此經常透過大型虛擬機平台實做，加上 Cluster API 達成相關的自動化。Cluster API\cite{clusterapi} 是 Kubernetes API 的延伸，透過自訂 resource 種類，將租戶叢集的管理以 controller 的方式實做，達成以一個管理用母叢集，控管多個租戶子叢集的形式，減少在維運上的負擔。Cluster API 在實作上具有擴充性設計，將節點運算資源環境與加入叢集方式分離，定義提供者界面，使虛擬化平台以及 Kubernetes 發行版供應商的支援皆可擴充開發，並且兩者可以自由搭配使用，目前已經支援大多數常見的公、私有雲虛擬機平台。

將大量叢集管理的想法再進一步延伸，有些手法另外會將叢集控制邏輯元件在部屬上與運算節點抽離，以其他方式統一代管。一方面避免租戶直接存取叢集關鍵元件，減少操作上的意外影響，提昇叢集整體可靠度，另一方面也降低多叢集在資源上的部份負擔。此類做法常見於直接提供 Kubernetes 服務的公有雲。

雖然基於叢集的多租戶具備功能完整、架構簡潔與高度隔離的優勢，並且已有 Cluster API 自動化以輔助管理。然而多叢集運算資源與管理開銷較大，本研究有上千個潛在的租戶，即使我們將控制邏輯元件集中管理，並且每個叢集只提供一個節點，犧牲節點層面的高可用性，仍然可能需要上千個虛擬機，考量到系計中的硬體資源，此方法並不實際。相較於上千個小型叢集，一個大型叢集較易於管理，也能大幅減少虛擬機數量，避免重複運行相同系統元件帶來的資源浪費。本研究沿襲 CScloud，採取單一叢集、基於 Namespace 的多租戶設計，並且將其加固以實踐硬多租戶，使用較低的資源成本，但仍提供可接受的安全性。另外我們將加固實作重新整理，以更低的開發維護成本與更新的技術實現。

\begin{table}[htb]
    \centering
    \caption{Kubernetes 硬多租戶實作形式彙整}
    \begin{tabular}{l || c | c }
        租戶切分方式 & 叢集 & Namespace \\
        \hline\hline
        實作主要議題 & 大量叢集管理自動化 & 單一叢集內部加固 \\ \hline
        典型的租戶隔離形式 & 虛擬機（叢集環境） & 容器 \\ \hline
        額外資源負擔 & 大 & 小 \\ \hline
        可用 Kubernetes 功能 & 完整 & 足以部屬網頁服務 \\ \hline
        開發負擔 & 小 & 大 \\ \hline
        管理負擔 & 大 & 小 \\
    \end{tabular}
\end{table}