From 22c79cb65829071d903c4508694697ce148c41b3 Mon Sep 17 00:00:00 2001 From: Pinghao Wu Date: Sat, 21 Sep 2024 16:20:25 +0800 Subject: [PATCH] Architecture: admission control, PodSecurity --- Sections/1.Introduction.tex | 2 ++ Sections/2.Backgrounds.tex | 8 +++++--- Sections/4.Architecture.tex | 28 ++++++++++++++++++++++++++-- 3 files changed, 33 insertions(+), 5 deletions(-) diff --git a/Sections/1.Introduction.tex b/Sections/1.Introduction.tex index 0c6d343..18dbbdc 100644 --- a/Sections/1.Introduction.tex +++ b/Sections/1.Introduction.tex @@ -9,11 +9,13 @@ 對於大量網站的集中管理，常見的方案依據平台對於網站性質的彈性，由低到高大致可以分為以下類別： +\begin{onehalfspacing} \begin{itemize} \item 靜態內容網頁代管 \item 特定內容管理系統（如： WordPress, Drupal 等）代管 \item 特定後端語言（如： PHP 等）代管 \end{itemize} +\end{onehalfspacing} 然而考量到資工系系上網頁技術的多元廣泛，以上的形式皆不足以滿足需求。其中若以特定內容管理系統或後端語言提供服務，在整個資工系的規模下，面對內容管理系統或語言本身的更迭，難免需要對特定使用者提供特定版本，以利使用者逐步進行版本更新，在管理上負擔特別大。 diff --git a/Sections/2.Backgrounds.tex b/Sections/2.Backgrounds.tex index 7de8792..b54defc 100644 --- a/Sections/2.Backgrounds.tex +++ b/Sections/2.Backgrounds.tex @@ -11,13 +11,15 @@ Kubernetes （簡稱 K8s）為一容器編排 (orchestration) 系統，其主要 Kubernetes 提供 RESTful API 做為主要控制手段，以 resources 作為對操作意圖的描述以及結果，將系統操作以非同步的形式建模為對 resources 進行讀寫，並且將系統大致切成兩大部份：負責提供 API 與 resources 資料存儲的 API 伺服器 (kube-apiserver)，以及實際實做 resources 所代表的操作的 controllers。典型的操作流程大致如下： +\begin{onehalfspacing} \begin{enumerate} - \item 使用者建立一 resource，並在其 spec 欄位描述需要的系統狀態 + \item 使用者建立一 resource，並在其 \verb|spec| 欄位描述需要的系統狀態 \item kube-apiserver 通知相關 controller 有新的 resource 創立 - \item controller 根據 spec 欄位進行操作，嘗試滿足 spec，並將結果存入 status 欄位 + \item controller 根據 \verb|spec| 欄位進行操作，嘗試滿足 \verb|spec|，並將結果存入 \verb|status| 欄位 \item kube-apiserver 通知使用者 resource 有所變更 - \item 使用者透過更新後的 status 欄位得知操作結果 + \item 使用者透過更新後的 \verb|status| 欄位得知操作結果 \end{enumerate} +\end{onehalfspacing} \begin{figure}[htb] \centering diff --git a/Sections/4.Architecture.tex b/Sections/4.Architecture.tex index fc82f73..8d813c7 100644 --- a/Sections/4.Architecture.tex +++ b/Sections/4.Architecture.tex @@ -7,10 +7,12 @@ 本研究目標設想的 Kubernetes-as-a-Service 可以藉由 CScloud 的想法衍生改良，保留其共用叢集、基於 Kubernetes namespace 的多租戶設計以及透過串接既有單一登入服務簡化身份驗證實做的特色，重新設計架構並著重於改善下列兩點： +\begin{onehalfspacing} \begin{itemize} \item \textbf{安全性}：改善對於系統元件的切分以及實做方法 \item \textbf{通用性}：跳脫 PaaS 的設計框架、充分發揮 Kubernetes 的潛力 \end{itemize} +\end{onehalfspacing} % 這看要不要往下丟到 propose 設計本身 由於架構變更，使得平台上自行撰寫的元件必須重新實做。以此為契機，我們採用可上線運行的高標準撰寫，並且著重其完備性，而非僅只進行機制的概念驗證。在實做過程中，我們也反覆審視此架構下對於使用者體驗的影響，並且透過擴展網頁界面功能以其他方式彌補。 @@ -41,11 +43,33 @@ CSKloud 達成一代願景中的開放使用者直接存取 Kubernetes API，使 在網頁界面的實做方面，由於 CSKloud 開放存取 Kubernetes API，可以將其直接作為網頁後端利用，而網頁界面本身透過 SPA 架構重新實做，免除另外維護網頁後端伺服器所產生的維運成本及資安考量，同時也可以利用 Kubernetes API 本身對資料更新的推送機制，搭配 SPA 動態控制內容的特性，達成即時的資訊更新，大幅地增強使用者體驗。同時將對於 Helm 的支援透過 WebAssembly 改由直接在瀏覽器端運行，並且將其功能完善，開放更多的 Helm Charts 提供安裝。 -\section{權限開通、叢集加固實做} +\section{叢集加固實做} + +由於 Kubernetes 的功能廣泛，有許多的功能具有較大的權限，間接具備控制整座叢集的能力，在一個共有的平台下，有部屬不受信任的工作負載的可能，使用 admission controllers 限制功能是必要的，對此我們以引入 Kubernetes 內建的 admission controllers 為主，輔以 CEL 進一步實做缺乏的邏輯。我們主要引入下列內建的 admission controllers： + +\begin{onehalfspacing} +\begin{itemize} + \item PodSecurity + \item PodTolerationRestriction + \item AlwaysPullImages +\end{itemize} +\end{onehalfspacing} + +\subsection{PodSecurity} + +容器一般被視為一個與宿主端 (host) 隔離的環境，但由於容器具有自成一體 (self-contained) 的特性，能夠大幅簡化部屬管理，在 Kubernetes 的場合更可以統一管理叢集內部各節點的容器，因此容器也常被用來部屬與宿主端有關的底層基礎設施。此場景需要局部地關閉容器的隔離功能，來達成如管理宿主端網路環境等操作。對此，Kubernetes 在 Pod 的 \verb|spec| 欄位設計多個開關，提供解除部份隔離機制的途徑。 + +即使並未關閉任何預設的隔離機制，對於一般的工作負載，我們也應遵循最小權限原則，例如以非 root 的身份執行等，對於容器內的執行身份，在 Pod 內也可以進行設定。另外，Kubernetes 除了傳統容器隔離技術外，也支援進一步設定其餘的安全與 mandatory access control (MAC)\footnote{MAC: 針對特定行程的操作與其目標（如讀寫特定檔案、使用特定網路資源）進行限制的機制。} 機制，例如 seccomp、SELinux、AppArmor 等。 + +面對如此多元的安全性相關設定，以及其產生的無數組合，我們需要一個標準評判 Pod 的安全性。Kubernetes 提出了 Pod Security Standards，並且將可能的設定分為三個政策層級：privileged、baseline 與 restricted。Privileged 可以放寬隔離機制，baseline 包含未特別指定任何設定的場景，restricted 則是進一步要求提升安全性設定。對於執行這些政策檢查，Kubernetes 提供了 PodSecurity admission controller。 + +大多數政策類型的 admission controllers，包含 PodSecurity，設計上皆能夠以 namespace 為單位設定政策，為了確保平台安全性，我們針對使用者的 namespaces 實施 restricted 政策。 + +\section{權限開通實做} \section{網頁界面實做} -進一步對網頁界面的需求分析，可以將網頁界面切分為兩大塊：支援 Helm 的通用 Kubernetes 網頁型客戶端，以及 CSKloud 特定的部份，包含權限開通元件的整合以及 CSKloud 平台面向使用者的文件等。其中 Kubernetes 客戶端很容易的就可以利用於其他場景，我們採取 open core 的策略，將其 Kubernetes 客戶端開放原始碼，以 MIT 授權條款\footnote{MIT license，一個在網頁技術場域廣受歡迎的寬鬆型開放原始碼條款。}釋出，命名為 Sparkles\footnote{Sparkles 釋出於 \url{https://github.com/xdavidwu/sparkles} 。}，回饋於社會，使得非平台使用者也能受益，同時可以也利用開放原始碼社群的力量來茁壯平台的發展。 +進一步對網頁界面的需求分析，可以將網頁界面切分為兩大塊：支援 Helm 的通用 Kubernetes 網頁型客戶端，以及 CSKloud 特定的部份，包含權限開通元件的整合以及 CSKloud 平台面向使用者的文件等。其中 Kubernetes 客戶端很容易的就可以利用於其他場景，我們採取 open core 的策略，將其 Kubernetes 客戶端開放原始碼，以 MIT 授權條款\footnote{MIT license: 一個在網頁技術場域廣受歡迎的寬鬆型開放原始碼條款。}釋出，命名為 Sparkles\footnote{Sparkles 釋出於 \url{https://github.com/xdavidwu/sparkles} 。}，回饋於社會，使得非平台使用者也能受益，同時可以也利用開放原始碼社群的力量來茁壯平台的發展。 \begin{figure}[htb] \centering -- 2.45.2