2 files changed, 5 insertions(+), 3 deletions(-)

M Sections/2.Backgrounds.tex
M Sections/3.RelatedWorks.tex

@@ 64,9 64,11 @@ OpenID Connect (OIDC)\cite{oidc} 則是一個基於 OAuth 框架衍生的身份
 
 Kubernetes 主要透過兩個機制達成使用者的存取控制，其一是 RBAC (Role-based access control)。RBAC 可以根據 resources 的種類、所在的 Namespace 或是特定的 resource 實例授予使用者對其進行各種操作的權力，包含創立、刪除、更新、獲取、列舉等，不同類型的操作可以分別授予\cite{rostami2023role}。
 
-另一個機制為 admission control，在 RBAC 後執行，可以根據被創立或更新的 resource 內容進行管控。實做控制邏輯的 admission controllers 主要又分為 mutating 與 validating 兩種。Mutating admission controllers 可以修改 resources 內容，常用於對 resource \verb|spec| 中的特定欄位賦予預設值。以 mutating admission controllers 賦予預設值的方法，比起在實做 resources 的 controller 定義預設行為，以使用者的角度更為明確，使用者可以觀察最終儲存的 resource 內容得知其行為，對於平台提供者，透過這個機制實做平台特定的預設值也更為方便。Validating admission controllers 則無法修改 resources 內容，只能做出允許或拒絕操作的決策，為了能夠驗證修改後的 resources 內容，編排在 mutating admission controllers 後執行，常用於執行特定設定上的管制政策。由於 Kubernetes 功能上的廣泛，不適合將每個功能都規劃成獨立的 resource 種類，用 RBAC 針對 resource 種類進行存取控制有時會顯得不足，admission control 便補足了這方面的彈性。
+另一個機制為 admission control，在 RBAC 後執行，可以根據被創立或更新的 resource 內容進行管控。實做控制邏輯的 admission controllers 主要又分為 mutating 與 validating 兩種。Mutating admission controllers 可以修改 resources 內容，常用於對 resource \verb|spec| 中的特定欄位賦予預設值。以 mutating admission controllers 賦予預設值的方法，比起在實做 resources 的 controller 定義預設行為，以使用者的角度更為明確，使用者可以觀察最終儲存的 resource 內容得知其行為，對於平台提供者，透過這個機制實做平台特定的預設值也更為方便。Validating admission controllers 則無法修改 resources 內容，只能做出允許或拒絕操作的決策，為了能夠驗證修改後的 resources 內容，編排在 mutating admission controllers 後執行，常用於執行特定設定上的管制政策。
 
-Kubernetes 內建許多 admission controllers，其中一些用來實做基本功能並預設啟用，如資源配額的部份邏輯。另外也有些預設停用的 admission controllers，提供給管理者進行平台加固或者調整行為使用。
+由於 Kubernetes 功能上的廣泛，不適合將每個功能都規劃成獨立的 resource 種類，用 RBAC 針對 resource 種類進行存取控制有時會顯得不足，admission control 便補足了這方面的彈性。例如在 Linux 系統下容器的隔離措施具備模組化設計，可以依據需求不使用特定措施，Kubernetes 的 Pod 也沿襲了這個設計，雖在特殊場景有其用途，但在其外卻可能導致容器得以滲透運行的節點。由於仍屬於 Pod 種類，在 RBAC 下無法獨立限制此類使用行為，需以 admission control 另外進行加固。
+
+Kubernetes 內建許多 admission controllers，其中一些用來實做基本功能並預設啟用，如資源配額的部份邏輯。另外也有些預設停用的 admission controllers，提供給管理者進行平台加固或者調整行為使用。這些 admission controllers 採取深度的切分設計，以適應多種不同的 Kubernetes 運用場景。如何針對場景配置各個 admission controllers，搭配出完整的解決方案，則是管理者需要專精研習的部份。
 
 對於內建的 admission controllers 不敷使用的場合，Kubernetes 提供兩個機制讓管理者進一步自訂邏輯：webhooks 與 Common Expression Language\cite{cel} （簡稱 CEL）。Webhooks 透過呼叫管理者提供的 HTTP API 達成，支援 mutating 與 validating，可以透過任何能架設 HTTP API 的語言編寫，在生態系上已經有多個框架可以協助開發，例如：Open Policy Agent 與 Kyverno 等。CEL 為一結構資料處理語言，常用以使軟體功能可程式化，Kubernetes 將其導入作為延伸 kube-apiserver 邏輯的手段。以 Kubernetes 1.31 而言，目前只有 validating 進入穩定狀態，對 mutating 的支援仍在開發。相對於 webhooks，使用 CEL 可以直接在 kube-apiserver 上執行邏輯，省略了呼叫 HTTP API 的網路溝通，減少造成的延遲影響與管理負擔，但能夠進行的操作受限於 Kubernetes 對其執行環境提供的函式庫。
 

@@ 35,7 35,7 @@
 
 軟多租戶指的是租戶間擁有一定程度的信任，在租戶間的隔離與安全性上的需求較低，而專注於防止租戶間的意外狀況影響，常見於同個公司內部的不同團隊。硬多租戶則是指租戶間無法存在信任，任一租戶都必須視為可能的攻擊者，在設計上必須以隔離、安全性為優先考量。本研究欲達成的目標較偏向硬多租戶。
 
-Kubernetes Namespaces 由於只影響 API 上能描述的 resources 相互關係，並不隱含實際工作負載的隔離，常用來實做軟多租戶。然而，透過 admission control 我們仍可為 resource 內容加以把關，強制使用者開啟對工作負載的額外隔離措施，彌補 Namespaces 在此方面的不足，使其更為貼近硬多租戶的目標。CScloud 即是採用此類方案，但同時帶來的是大量的額外加固開發成本以確保租戶間的獨立性。
+Kubernetes Namespaces 由於只影響 API 上能描述的 resources 相互關係，並不隱含實際工作負載的隔離，常用來實做軟多租戶。然而，透過 admission control 我們仍可為 resource 內容加以把關，確保使用者在其他層面啟用對工作負載的隔離措施，防止在共用叢集的架構下影響其他租戶，彌補 Namespaces 在此方面的不足，使整體更為貼近硬多租戶的目標。CScloud 即是採用此類方案，但同時帶來的是大量的 admission control 加固開發成本。
 
 在硬多租戶的議題下，另一個常見許多的手法則是基於叢集的多租戶模型，透過給予每個租戶獨立的叢集，進而免除對叢集內部的大多數加固需求，以高層次架構來看單純許多，並且租戶能夠使用較完整的 Kubernetes 功能。