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

M Sections/6.Conclusion.tex

@@ 9,12 9,18 @@
 
 在 Kubernetes 下，所有的 Pods 皆處於一個至少自第三層（L3，網路層）互通的網路環境，亦即在不加以限制下，任何 Pod 皆能與其他 Pod 溝通。在我們的單一叢集多租戶架構下，我們應確保不同租戶間的 Pods 不能互相溝通，作為資安防禦手段。
 
-Kubernetes 定義了 NetworkPolicy 種類，以設定 Pod 的防火牆規則，需搭配具備相關支援的 Container Network Interface (CNI)\footnote{CNI: Kubernetes 對於其叢集內部網路實做提供的抽象定義，市面上有多個不同實做可供選擇。} 實做。為了往後實做租戶間的網路隔離，在架構叢集期間我們即採用支援 NetworkPolicy 的 Calico\footnote{Calico: CNI 實做，其主要特色為大量採用 L3 網路，異於傳統牽涉 L2 的方案，有助於簡化架構。} 做為 CNI 實做。
+Kubernetes 定義了 NetworkPolicy 種類，以設定 Pod 的防火牆規則，需搭配具備相關支援的 Container Network Interface (CNI)\footnote{CNI: Kubernetes 對於其叢集內部網路實做提供的界面定義，市面上有多個不同實做可供選擇。} 實做。為了往後實做租戶間的網路隔離，在架構叢集期間我們即採用支援 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 實做的方案對於實際容器運行皆會增加運算負擔，甚至牽涉虛擬化技術，一定程度的降低容器在資源運用上的優勢。而對於 CRI 額外加固則是需要對系統運作與典型工作負載有相當深入的理解，在開發上的負擔不容小覷。面對如此多元的解決方案，我們需要進一步實驗進行權衡，在成本與安全性中找尋平衡點。將系統正式上線、對平台需求規模有更明確深入的認知也將有助於這方面的分析。
+
 \subsection{Control plane 虛擬化}
 
 \subsection{基礎設施代管}