\chapter{結論與未來展望}
\label{ch:conclusion}

\section{結論}

我們開發出了一個採用 Namespace 作為多租戶基礎的 Kubernetes-as-a-Service 平台，針對硬多租戶模型，並且面向以有限硬體資源容納大量低用量租戶的場景設計，有著低運算負擔，但仍保持一定安全性的特色。平台帶有域名使用權管控機制，著重但不限於網頁服務的代管。

根據此類平台常見的網頁形式界面需求，我們開發出了通用的 Kubernetes 客戶端，再針對平台特性提供特定功能整合以便使用，並將其成果開源釋出，即使非平台使用者，仍能從其獲益。而對於平台的多租戶實作以及相關加固，我們也透過現代技術，針對管理自動化以及減少未來維運負擔設計。另外由於硬體資源配給以及相關維運規劃等尚待進一步實行，平台尚未對外開放使用，但已經於系計中對內測試，由 PSSUQ 問卷評估，達到相當正面的反饋。

\section{未來展望}

雖然本研究開發出的 Kubernetes-as-a-Service 平台已經具有可接受的安全性以及十分廣泛的通用性，這兩點皆可以進一步考慮其他方案持續改良，而平台的功能也有進一步拓展的空間。

\subsection{租戶間的網路隔離}

在 Kubernetes 下，所有的 Pods 皆處於一個至少自第三層（L3，網路層）互通的網路環境，亦即在不加以限制下，任何 Pod 皆能與其他 Pod 溝通。在我們的單一叢集多租戶架構下，我們應確保不同租戶間的 Pods 不能互相溝通，作為資安防禦手段。

Kubernetes 定義了 NetworkPolicy 種類，以設定 Pod 的防火牆規則，需搭配具備相關支援的 Container Network Interface (CNI)\footnote{CNI: Kubernetes 對於其叢集內部網路實作提供的界面定義，市面上有多個不同實作可供選擇。}\cite{qi2020assessing} 實作。為了往後實做租戶間的網路隔離，在架構叢集期間我們即採用支援 NetworkPolicy 的 Calico\footnote{Calico: CNI 實作，其主要特色為大量採用 L3 網路，異於傳統牽涉 L2 的方案，有助於簡化架構。} 做為 CNI 實作。

然而 NetworkPolicy 同時也常用於使用者自行針對工作負載所需而擬定的網路加固，在一般常見的存取控制機制下，較難實施平台端硬性的全域政策。目前預見可能的實做路徑有針對此情景進一步特別設計修改存取控制，或者使用特定 CNI 實作的專屬方案，如 Calico 的 GlobalNetworkPolicy resource 種類。

\subsection{容器運行環境加固}

對於容器運行環境，我們使用 \ref{sec:PodSecurity} \verb|PodSecurity| admission controller 針對 Pod 的安全性相關設定加以政策限制，然而這個作法導致使用者必需填寫原本非必填的欄位，在使用者體驗上不甚理想。一個直觀的解決方法是利用 mutating admission control 邏輯去自動補填相關欄位，然而這樣容易引發使用者預期外的行為，較不利於使用者除錯。另一個解決方向則是在更底層進行加固，使得在使用者不須調整相關設定、大致上不影響工作負載行為的前提下，仍然保有一定的平台安全性，免除對 \verb|PodSecurity| 與配置安全性設定的依賴。

這類型的方法大多牽涉調整 Container Runtime Interface (CRI)\footnote{CRI: Kubernetes 對於 Pod 與容器的實際執行實作提供的界面定義。}，修改其實作或者對其額外加固。修改 CRI 實作的方案有：將容器運行在獨立的虛擬機內（如：Kata Containers、Edera krata）、攔截部份系統呼叫於 user space\footnote{User space: 作業系統供程式運行的環境，相對於核心的 kernel space，user space 具有較低的權限。} 重新實做（如：gVisor）。而對 CRI 進行加固的方法主要是透過 mandatory access control（MAC，如：SELinux、AppArmor），Kubernetes 在 API 設計上允許 CRI 層自行提供 MAC 的政策定義，我們可以針對平台需求修改為更加嚴格的政策。

修改 CRI 實作的方案對於實際容器運行皆會增加運算負擔，甚至牽涉虛擬化技術，一定程度的降低容器在資源運用上的優勢\cite{espe2020performance}\cite{viktorsson2020security}。而對於 CRI 額外加固則是需要對系統運作與典型工作負載有相當深入的理解，在開發上的負擔不容小覷。面對如此多元的解決方案，我們需要進一步實驗進行權衡，在成本與安全性中找尋平衡點。將系統正式上線、對平台需求規模有更明確深入的認知也將有助於這方面的分析。

\subsection{Control plane 虛擬化}

本研究設計的平台在通用性的侷限來自於共用叢集的架構設計，需透過權限切分容納多個租戶，導致租戶無法存取叢集的完整功能，其中最大的影響是使用者無法自行註冊對 Kubernetes API 的拓展。近期除了以 Helm Charts 交付軟體產品外，也逐漸流行以 operator pattern 另外開發 operator，自動化更為複雜的軟體部屬場景。無法自行拓展 Kubernetes API 也導致了使用者無法安裝這類型的產品。

一個可能的解法是管理員先行安裝常見的 operators，搭配設定 RBAC 使得使用者仍然可以由其部屬軟體，但 operators 採取能夠控制整個叢集相關 resources 的權限運行，需要嚴格審視其設計實作的安全性，避免使用者經由 operators 達成提權，在管理上潛藏著不小的負擔。若管理員不熟悉單叢集多租戶設計，更容易忽略此類攻擊路徑。

另一個可能的想法是貫徹 control plane 與 worker nodes 的切分概念，將 control plane 進一步進行虛擬化，使得每個租戶皆有專屬的完整虛擬 control plane，能夠存取更完整的 Kubernetes 功能，而實際 worker nodes 節點仍為共用，比多個完整叢集具備較少的資源負擔\cite{zheng2021multi}。然而系計中此前未有類似需求，對於 control plane 虛擬化相當陌生，需要更多實驗來了解其維運成本。

\subsection{基礎設施代管}

系計中在維運上除了最基礎的硬體、儲存設備與底層虛擬化平台外，軟體服務鮮少有直接購買解決方案的場景，大多採取自行維運相關基礎設施。對於網頁場景，由平日經驗中觀察，維運難度最高的是資料庫。建立一個資料庫並不複雜，但將資料庫運行的好需要設立多個實例，之間要有即時的資料複製機制，並且實做高可用性。具備高可用性的資料庫叢集雖然可靠，但萬一仍遇到罕見災難場景，其手動復原也需要對備援原理有相當深入的理解。即使 Kubernetes 本身對於高可用性已經有部份機制，牽涉到資料儲存仍然有相當大的成份需要自行處理。

對於資料庫這種高維運成本，又有標準界面的基礎設施，即使是主要提供底層平台的雲端廠商，也常有提供完整的高層次設施代管服務，降低客戶的負擔。我們或許可以利用維運經驗，提供類似的服務，使得平台使用更為簡便，同時減少租戶個別架設資料庫所產生的資源浪費。

\subsection{使用者以外的租戶形式}

本研究實做了以使用者為單位的租戶形式，但對於系上的需求，仍然有部份場景脫離使用者的框架，有更高層次的租戶單位較為理想。例如實驗室或者課程場景，雖然目前已經可以由使用者自行設定 RBAC，授權其他使用者存取資源，但對於這類較為公務的需求，有個獨立的配額與私人運用分離較為友善。

我們在 \ref{sec:provisioner} 權限開通設計已經留有拓展租戶設計的空間，如 Namespace 與平台提供域名的命名上皆帶有租戶形式。但面對高層次的租戶，仍然有其使用者管理以及申請的行政流程等可預見的議題需要進一步處理設計。在使用者屬於多個租戶單位的情況下，網頁界面得知使用者能夠存取的 Namespaces 的機制也需要另外擬定。令使用者能夠列舉叢集的所有 Namespaces 容易產生隱私問題或管理資訊的洩漏，解決這方面的需求可能需要再行擴展 Kubernetes API。