4 files changed, 39 insertions(+), 39 deletions(-)

M Sections/2.Backgrounds.tex
M Sections/3.RelatedWorks.tex
M Sections/4.Architecture.tex
M Sections/6.Conclusion.tex

@@ 27,7 27,7 @@ Kubernetes 提供 RESTful API 做為主要控制手段，以 resources 代表操
     \caption{Kubernetes 運作模型簡易示意圖}
 \end{figure}
 
-此架構使得 Kubernetes 在功能面上極易擴展，只須對 kube-apiserver 註冊一個新的 resource 種類，並且實做相關 controller 邏輯，便可以擴展 Kubernetes API。運用此機制開發軟體又稱為 operator pattern，將 controller 比擬為自動的營運者。kube-apiserver 除了資料存儲以外，也包含了基本的資料驗證、身份驗證以及相關授權機制，使得 controller 能夠更專注於達成 resource 邏輯的實做，減少擴展開發者的負擔。同時在 resource 本身的設計上，也會盡量使描述的操作是可被重複執行的 (idempotent)，令 controller 不須額外維護內部狀態 (stateless)，簡化 controller 的部屬管理以及提高容錯空間，使整體系統更為易用且可靠。
+此架構使得 Kubernetes 在功能面上極易擴展，只須對 kube-apiserver 註冊一個新的 resource 種類，並且實做相關 controller 邏輯，便可以擴展 Kubernetes API。運用此機制開發軟體又稱為 operator pattern，將 controller 比擬為自動的營運者。kube-apiserver 除了資料存儲以外，也包含了基本的資料驗證、身份驗證以及相關授權機制，使得 controller 能夠更專注於達成 resource 邏輯的實作，減少擴展開發者的負擔。同時在 resource 本身的設計上，也會盡量使描述的操作是可被重複執行的 (idempotent)，令 controller 不須額外維護內部狀態 (stateless)，簡化 controller 的部屬管理以及提高容錯空間，使整體系統更為易用且可靠。
 
 \begin{figure}[htb]
     \centering


@@ 81,7 81,7 @@ Kubernetes 提供多個身份驗證手段，可搭配混合使用，在設計上
     \caption{Kubernetes 身份驗證手段簡易示意圖}
 \end{figure}
 
-Kubernetes 中的 X.509 憑證即為 TLS 客戶端憑證 (client certificate)，在 TLS 的驗證模型下，除了伺服器端需要提供憑證證明本身的真實性以外，客戶端也可以提供憑證，使伺服器端得以驗證客戶端的身份 (client certificate authentication, CCA)。此機制近期又以 mutual TLS (mTLS) 的名稱流行，強調雙方都可以驗證彼此的身份。Kubernetes 將身份名稱與所在群組存放在客戶端憑證的 Subject 屬性內，並且要求憑證來自特定的簽發單位 (certificate authority, CA)，通常直接由叢集管理，藉此確保資訊的真實性。雖然 X.509 標準有定義憑證的撤銷機制\cite{rfc5280}\cite{rfc6960}，但目前 Kubernetes 並沒有相關實做，導致只能利用簽發短效期的憑證，達到金鑰洩漏場景的減災。缺乏撤銷機制也使得這個驗證方法不易修改身份資訊。由於客戶端憑證較不方便使用，尤其需要透過頻繁換發短效期憑證達到安全性，相關自動化成本較高，除了叢集內部元件的身份驗證外，較不常用於使用者端，多見於非正式環境，或是另外嚴謹保存作為管理者的備用手段。
+Kubernetes 中的 X.509 憑證即為 TLS 客戶端憑證 (client certificate)，在 TLS 的驗證模型下，除了伺服器端需要提供憑證證明本身的真實性以外，客戶端也可以提供憑證，使伺服器端得以驗證客戶端的身份 (client certificate authentication, CCA)。此機制近期又以 mutual TLS (mTLS) 的名稱流行，強調雙方都可以驗證彼此的身份。Kubernetes 將身份名稱與所在群組存放在客戶端憑證的 Subject 屬性內，並且要求憑證來自特定的簽發單位 (certificate authority, CA)，通常直接由叢集管理，藉此確保資訊的真實性。雖然 X.509 標準有定義憑證的撤銷機制\cite{rfc5280}\cite{rfc6960}，但目前 Kubernetes 並沒有相關實作，導致只能利用簽發短效期的憑證，達到金鑰洩漏場景的減災。缺乏撤銷機制也使得這個驗證方法不易修改身份資訊。由於客戶端憑證較不方便使用，尤其需要透過頻繁換發短效期憑證達到安全性，相關自動化成本較高，除了叢集內部元件的身份驗證外，較不常用於使用者端，多見於非正式環境，或是另外嚴謹保存作為管理者的備用手段。
 
 Authenticating proxy 透過在 Kubernetes API 之前加一層代理伺服器進行驗證邏輯。在將請求轉發給 Kubernetes API 時，代理伺服器會加上約定的 HTTP headers 以表達使用者身份。對於代理伺服器驗證使用者的方式並沒有限制。這個方法等同於將驗證邏輯直接抽出另外自行實做，相當富有彈性，但開發成本較高，並且需自行注意撤銷等機制是否完善。
 


@@ 135,7 135,7 @@ Helm 使得在 Kubernetes 叢集上安裝軟體變得相當簡便，Helm Chart 
 
 \section{Single-Page Application}
 
-Single-Page Application （簡稱 SPA）是一種網頁架構。傳統網頁架構由伺服器端控制網頁內容，在伺服器上執行模板輸出 HTML。SPA 則以 API 的形式從伺服器端獲取資料，再由瀏覽器端執行呈現邏輯。以瀏覽器端控制呈現可以局部的修改 HTML，在不重新載入整個頁面的情況下達到動態的資料更新。SPA 同時也以瀏覽器端邏輯控制頁面導覽，透過局部更新使在不同頁面間的轉換更為順暢。不同網址的頁面實質上是以同樣的起始 HTML 載入瀏覽器端程式碼，再經由程式碼中的分流邏輯根據網址做不同的呈現。比起傳統網頁架構，SPA 除了能達成更流暢的使用者體驗外，因為將呈現邏輯移到了瀏覽器端，於伺服器端的負擔降低，在運行成本上也有相當的優勢。在網頁編寫上，將資料處理（伺服器端）與資料呈現（瀏覽器端）分離，也有助於將兩者使用不同語言或框架，分別採用對更擅長於該方面的產品實做。
+Single-Page Application （簡稱 SPA）是一種網頁架構。傳統網頁架構由伺服器端控制網頁內容，在伺服器上執行模板輸出 HTML。SPA 則以 API 的形式從伺服器端獲取資料，再由瀏覽器端執行呈現邏輯。以瀏覽器端控制呈現可以局部的修改 HTML，在不重新載入整個頁面的情況下達到動態的資料更新。SPA 同時也以瀏覽器端邏輯控制頁面導覽，透過局部更新使在不同頁面間的轉換更為順暢。不同網址的頁面實質上是以同樣的起始 HTML 載入瀏覽器端程式碼，再經由程式碼中的分流邏輯根據網址做不同的呈現。比起傳統網頁架構，SPA 除了能達成更流暢的使用者體驗外，因為將呈現邏輯移到了瀏覽器端，於伺服器端的負擔降低，在運行成本上也有相當的優勢。在網頁編寫上，將資料處理（伺服器端）與資料呈現（瀏覽器端）分離，也有助於將兩者使用不同語言或框架，分別採用對更擅長於該方面的產品實作。
 
 \section{WebAssembly}
 

@@ 5,29 5,29 @@
 
 \section{CScloud}
 
-先前系計中已經有意識到基於容器的網頁服務代管平台需求，發展出一套雛型系統，並且歷經兩代變革，分別為 CScloud\cite{cskloud} 與 CScloud with PEKOS (Policy-Enforced Kubernetes OAuth System)\cite{pekos}，本文以「一代」與「二代」代稱。雖然發展已久，但實做仍不完全，並未上線開放使用，在架構規劃也有部份缺點。以下簡略帶過其歷史沿革，並以二代為主進行介紹。
+先前系計中已經有意識到基於容器的網頁服務代管平台需求，發展出一套雛型系統，並且歷經兩代變革，分別為 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 邏輯，同時也以此實做域名使用權管控機制。二代系統雖然已經可以運作，具有些許的基本功能，卻因為實做皆以概念驗證的角度撰寫，品質並不適合開放使用，導致系計中內部普遍對系統有安全性疑慮，並未實際上線運行。
+二代系統沿襲了一代對於多租戶與資源配額的設計，另外將身份驗證以 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 實做架構簡易示意圖}
+    \caption{CScloud with PEKOS 實作架構簡易示意圖}
 \end{figure}
 
-在實做方面，為了避免同時使用 LDAP、OIDC 兩個協定在類似的場景，二代去除了一代使用自訂 Kubernetes resource 種類實做的 LDAP 使用者開通功能，取而代之的是由網頁界面本身，在使用者首次登入時進行相關的開通，而開通後的互動皆由使用者對應的身份操作 Kubernetes。
+在實作方面，為了避免同時使用 LDAP、OIDC 兩個協定在類似的場景，二代去除了一代使用自訂 Kubernetes resource 種類實做的 LDAP 使用者開通功能，取而代之的是由網頁界面本身，在使用者首次登入時進行相關的開通，而開通後的互動皆由使用者對應的身份操作 Kubernetes。
 
 二代安裝少數特定軟體的功能實質是使用 Helm 實做，但網頁界面僅提供極少數的 Helm Charts 開放使用，並由程式邏輯產生其 Helm Values 設定，使用者無法對安裝設定（例如資源配置等）做任何修改。由相同的機制可以將功能推廣至其他應用的安裝，以達成一代規劃藉由 Helm 簡化系統使用的願景，但需要人力為每個應用逐一撰寫產生 Values 的邏輯，過於勞力密集且十分缺乏彈性，並且尚未實做更新、回滾等功能。
 
-在部屬單一網頁服務的部份，則是先設計一個部屬設定客製化表單，再透過填入固定的 resources 模板達成，由開發者自行設想的使用需求出發，因此成果也容易顯得相當侷限。以這個角度設計容易忽略部份需求，而帶有過多的假設，例如：假定只須一個容器、假定容器提供服務的 HTTP port number 等，並且無法相容於如安裝資料庫等網頁服務本體外的基礎建設場景。另外，基於模板的概念與 Helm 相似，實做上還有統一簡化的空間。
+在部屬單一網頁服務的部份，則是先設計一個部屬設定客製化表單，再透過填入固定的 resources 模板達成，由開發者自行設想的使用需求出發，因此成果也容易顯得相當侷限。以這個角度設計容易忽略部份需求，而帶有過多的假設，例如：假定只須一個容器、假定容器提供服務的 HTTP port number 等，並且無法相容於如安裝資料庫等網頁服務本體外的基礎建設場景。另外，基於模板的概念與 Helm 相似，實作上還有統一簡化的空間。
 
-二代的網頁界面實做採用單體式的傳統架構，包含使用者開通的功能，全部由單一一個網頁後端伺服器負責。使用者開通是藉由管理者身份存取 Kubernetes API 達成，管理者的驗證相關資訊必須在存放在網頁伺服器上，單體式的架構使得這部份有過大的潛在攻擊面，其他功能的程式碼紕漏可能會導致管理者金鑰外洩，使攻擊者得以藉此控制整座叢集。
+二代的網頁界面實作採用單體式的傳統架構，包含使用者開通的功能，全部由單一一個網頁後端伺服器負責。使用者開通是藉由管理者身份存取 Kubernetes API 達成，管理者的驗證相關資訊必須在存放在網頁伺服器上，單體式的架構使得這部份有過大的潛在攻擊面，其他功能的程式碼紕漏可能會導致管理者金鑰外洩，使攻擊者得以藉此控制整座叢集。
 
 在安裝特定軟體的方面，因為使用的程式語言 PHP 與 Helm 所採用的 Go 不符，二代採取以執行指令操作伺服器上的 Helm CLI 達成。這種方式雖然易於實做，但也容易產生使用者能夠注入其他指令或是預期外的參數等漏洞，影響到伺服器的安全。
 
-由於 Kubernetes 非同步的設計，狀態更新的推送顯得十分重要，而二代的網頁實做並沒有針對這點設計，而是仰賴於完整的頁面刷新，這也可能造成過度重複執行其餘資料未變更的邏輯運算，間接使得運行成本增加。
+由於 Kubernetes 非同步的設計，狀態更新的推送顯得十分重要，而二代的網頁實作並沒有針對這點設計，而是仰賴於完整的頁面刷新，這也可能造成過度重複執行其餘資料未變更的邏輯運算，間接使得運行成本增加。
 
 \section{Kubernetes 的多租戶模型}
 


@@ 39,19 39,19 @@ Kubernetes Namespaces 由於只影響 API 上能描述的 resources 相互關係
 
 在硬多租戶的議題下，另一個常見許多的手法則是基於叢集的多租戶模型，透過給予每個租戶獨立的叢集，進而免除對叢集內部的大多數加固需求，以高層次架構來看單純許多，並且租戶能夠使用較完整的 Kubernetes 功能。
 
-基於叢集的多租戶需要動態的配置多個獨立叢集與節點，因此經常透過大型虛擬機平台實做，加上 Cluster API 達成相關的自動化。Cluster API\cite{clusterapi} 是 Kubernetes API 的延伸，透過自訂 resource 種類，將租戶叢集的管理以 controller 的方式實做，達成以一個管理用母叢集，控管多個租戶子叢集的形式，減少在維運上的負擔。Cluster API 在實做上具有擴充性設計，將節點運算資源環境與加入叢集方式分離，定義提供者界面，使虛擬化平台以及 Kubernetes 發行版供應商的支援皆可擴充開發，並且兩者可以自由搭配使用，目前已經支援大多數常見的公、私有雲虛擬機平台。
+基於叢集的多租戶需要動態的配置多個獨立叢集與節點，因此經常透過大型虛擬機平台實做，加上 Cluster API 達成相關的自動化。Cluster API\cite{clusterapi} 是 Kubernetes API 的延伸，透過自訂 resource 種類，將租戶叢集的管理以 controller 的方式實做，達成以一個管理用母叢集，控管多個租戶子叢集的形式，減少在維運上的負擔。Cluster API 在實作上具有擴充性設計，將節點運算資源環境與加入叢集方式分離，定義提供者界面，使虛擬化平台以及 Kubernetes 發行版供應商的支援皆可擴充開發，並且兩者可以自由搭配使用，目前已經支援大多數常見的公、私有雲虛擬機平台。
 
 將大量叢集管理的想法再進一步延伸，有些手法另外會將叢集控制邏輯元件在部屬上與運算節點抽離，以其他方式統一代管。一方面避免租戶直接存取叢集關鍵元件，減少操作上的意外影響，提昇叢集整體可靠度，另一方面也降低多叢集在資源上的部份負擔。此類做法常見於直接提供 Kubernetes 服務的公有雲。
 
-雖然基於叢集的多租戶具備功能完整、架構簡潔與高度隔離的優勢，並且已有 Cluster API 自動化以輔助管理。然而多叢集運算資源與管理開銷較大，本研究有上千個潛在的租戶，即使我們將控制邏輯元件集中管理，並且每個叢集只提供一個節點，犧牲節點層面的高可用性，仍然可能需要上千個虛擬機，考量到系計中的硬體資源，此方法並不實際。相較於上千個小型叢集，一個大型叢集較易於管理，也能大幅減少虛擬機數量，避免重複運行相同系統元件帶來的資源浪費。本研究沿襲 CScloud，採取單一叢集、基於 Namespace 的多租戶設計，並且將其加固以實踐硬多租戶，使用較低的資源成本，但仍提供可接受的安全性。另外我們將加固實做重新整理，以更低的開發維護成本與更新的技術實現。
+雖然基於叢集的多租戶具備功能完整、架構簡潔與高度隔離的優勢，並且已有 Cluster API 自動化以輔助管理。然而多叢集運算資源與管理開銷較大，本研究有上千個潛在的租戶，即使我們將控制邏輯元件集中管理，並且每個叢集只提供一個節點，犧牲節點層面的高可用性，仍然可能需要上千個虛擬機，考量到系計中的硬體資源，此方法並不實際。相較於上千個小型叢集，一個大型叢集較易於管理，也能大幅減少虛擬機數量，避免重複運行相同系統元件帶來的資源浪費。本研究沿襲 CScloud，採取單一叢集、基於 Namespace 的多租戶設計，並且將其加固以實踐硬多租戶，使用較低的資源成本，但仍提供可接受的安全性。另外我們將加固實作重新整理，以更低的開發維護成本與更新的技術實現。
 
 \begin{table}[htb]
     \centering
-    \caption{Kubernetes 硬多租戶實做形式彙整}
+    \caption{Kubernetes 硬多租戶實作形式彙整}
     \begin{tabular}{l || c | c }
         租戶切分方式 & 叢集 & Namespace \\
         \hline\hline
-        實做主要議題 & 大量叢集管理自動化 & 單一叢集內部加固 \\ \hline
+        實作主要議題 & 大量叢集管理自動化 & 單一叢集內部加固 \\ \hline
         典型的租戶隔離形式 & 虛擬機（叢集環境） & 容器 \\ \hline
         額外資源負擔 & 大 & 小 \\ \hline
         可用 Kubernetes 功能 & 完整 & 足以部屬網頁服務 \\ \hline

@@ 1,15 1,15 @@
-\chapter{設計方法與實做}
+\chapter{設計方法與實作}
 \label{ch:architecture}
 
-本章節敘述本研究吸收 CScloud 的想法，重新設計出的 CSKloud v3 架構，其實做方法，以及網頁界面的功能性。
+本章節敘述本研究吸收 CScloud 的想法，重新設計出的 CSKloud v3 架構，其實作方法，以及網頁界面的功能性。
 
 \section{設計需求}
 
-為達成本研究目標設想的 Kubernetes-as-a-Service，我們將 CScloud 的想法衍生改良，保留其共用叢集、基於 Namespace 的多租戶設計以及透過串接既有單一登入服務簡化身份驗證實做的特色，重新設計架構並著重於改善下列兩點：
+為達成本研究目標設想的 Kubernetes-as-a-Service，我們將 CScloud 的想法衍生改良，保留其共用叢集、基於 Namespace 的多租戶設計以及透過串接既有單一登入服務簡化身份驗證實作的特色，重新設計架構並著重於改善下列兩點：
 
 \begin{onehalfspacing}
 \begin{itemize}
-    \item \textbf{安全性}：改善對於系統元件的切分以及實做方法
+    \item \textbf{安全性}：改善對於系統元件的切分以及實作方法
     \item \textbf{通用性}：跳脫 PaaS 的設計框架、充分發揮 Kubernetes 的潛力
 \end{itemize}
 \end{onehalfspacing}


@@ 18,13 18,13 @@
 
 \subsection{安全性}
 
-二代架構設計將需要高權限、低使用量的使用者開通元件以及低權限、高使用量的使用者互動界面實做為單一一個單體式網頁服務，不同權限層級的操作間欠缺隔離手段。另外在實做上也欠缺資訊安全意識，其根據使用者輸入在伺服器端呼叫 Helm CLI 的方式也容易產生漏洞。完全仰賴自行定義的 admission control 邏輯進行叢集本身的加固，由於 Kubernetes API 的複雜性，也容易由於未充分理解而有所缺失。
+二代架構設計將需要高權限、低使用量的使用者開通元件以及低權限、高使用量的使用者互動界面實做為一個單體式網頁服務，不同權限層級的操作間欠缺隔離手段。另外在實作上也欠缺資訊安全意識，其根據使用者輸入在伺服器端呼叫 Helm CLI 的方式也容易產生漏洞。完全仰賴自行定義的 admission control 邏輯進行叢集本身的加固，由於 Kubernetes API 的複雜性，也容易由於未充分理解而有所缺失。
 
-以系計中在運作方面上的特色而言，其主力開發人員來自於碩士班研究生以及部份學士班的打工，更迭極為頻繁快速，且提供的服務眾多，難以分配專屬人力，一人經常身兼多職維護多個產品，歷史上僅有少數人能夠深入了解既有服務實做細節。面對這樣的場景，以及考量到本平台的重要性，由初步規劃即必須嚴謹考量資訊安全，從架構起手進行防禦，以免在日後他人迭代維護時產生紕漏。
+以系計中在運作方面上的特色而言，其主力開發人員來自於碩士班研究生以及部份學士班的打工，更迭極為頻繁快速，且提供的服務眾多，難以分配專屬人力，一人經常身兼多職維護多個產品，歷史上僅有少數人能夠深入了解既有服務實作細節。面對這樣的場景，以及考量到本平台的重要性，由初步規劃即必須嚴謹考量資訊安全，從架構起手進行防禦，以免在日後他人迭代維護時產生紕漏。
 
 \subsection{通用性}
 
-二代並沒有達成一代對於開放直接使用 Kubernetes API 的想法，欠缺通用性，在網頁控制界面的實做亦是以新的 PaaS 平台角度出發，Kubernetes 僅只屬於達成平台的手段，這樣的實做脈絡容易侷限於自身的使用經驗，而忽略其他潛在的需求。同樣由於系計中人力更迭迅速的特性，較不利於累積經驗，這個方式難以產出功能全面的產品。Kubernetes 本身經過時間的洗禮，已發展為高度彈性且經過廣泛採用歷練的服務部屬框架，應由直接利用 Kubernetes 的角度設計，即可低成本的達成高通用性。
+二代並沒有達成一代對於開放直接使用 Kubernetes API 的想法，欠缺通用性，在網頁控制界面的實作亦是以新的 PaaS 平台角度出發，Kubernetes 僅只屬於達成平台的手段，這樣的實作脈絡容易侷限於自身的使用經驗，而忽略其他潛在的需求。同樣由於系計中人力更迭迅速的特性，較不利於累積經驗，這個方式難以產出功能全面的產品。Kubernetes 本身經過時間的洗禮，已發展為高度彈性且經過廣泛採用歷練的服務部屬框架，應由直接利用 Kubernetes 的角度設計，即可低成本的達成高通用性。
 
 \section{CSKloud v3 架構設計}
 


@@ 42,9 42,9 @@ CSKloud 達成一代願景中的開放使用者直接存取 Kubernetes API，使
 
 此網頁界面預計不論是具備 Kubernetes 經驗的老手，或是剛入門的新手都能從中獲益。我們將透過提供編輯器與 resource 種類定義整合，提供更好的 resources 撰寫與瀏覽體驗，彌補此場域在整合式開發環境的希缺，對於探索學習 Kubernetes 功能或者日常使用皆有所幫助。另外我們以 Helm 達成完整的應用程式安裝管理功能，提供高層次、步驟式的圖形化操作界面，有利於新手快速的達成安裝常見軟體的基本任務。
 
-在實做方面，由於 CSKloud 開放存取 Kubernetes API，可以將其直接作為網頁後端利用，因此採用 SPA 架構重新實做網頁界面，免除另外維護網頁後端伺服器所產生的維運成本及資安顧慮，同時也利用 Kubernetes API 對資料更新的推送機制，搭配 SPA 動態控制內容的特性，達成即時的資訊更新，大幅地增強使用者體驗。另外將對於 Helm 的支援透過 WebAssembly 改由直接在瀏覽器端運行，並且將其功能完善，開放更多的 Helm Charts 提供安裝。
+在實作方面，由於 CSKloud 開放存取 Kubernetes API，可以將其直接作為網頁後端利用，因此採用 SPA 架構重新實做網頁界面，免除另外維護網頁後端伺服器所產生的維運成本及資安顧慮，同時也利用 Kubernetes API 對資料更新的推送機制，搭配 SPA 動態控制內容的特性，達成即時的資訊更新，大幅地增強使用者體驗。另外將對於 Helm 的支援透過 WebAssembly 改由直接在瀏覽器端運行，並且將其功能完善，開放更多的 Helm Charts 提供安裝。
 
-\section{叢集加固實做}
+\section{叢集加固實作}
 
 Kubernetes 功能廣泛，有許多功能牽涉較大的作業系統權限，間接具備控制整座叢集的能力。共有的平台有被部屬不受信任的工作負載之可能，使用 admission control 限制功能是必要的。對此我們以引入 Kubernetes 內建的 admission controllers 為主，輔以 CEL 進一步實做缺乏的邏輯。我們主要引入下列內建的 admission controllers：
 


@@ 104,7 104,7 @@ Kubernetes 中容器 images 的下載策略（\verb|imagePullPolicy| 欄位）
 
 另一個需要自訂邏輯的場景是域名使用權的管控。針對用來設定反向代理的 Ingresses，我們一樣先判斷操作的 Namespace 是否為使用者面向的，再進一步進行限制。需要限制的有：禁止使用 \verb|defaultBackend| 欄位（全域、不符合任何規則時的 fallback route），以及所有反向代理規則中的 \verb|host| 必須要符合域名白名單。白名單參考其餘政策相關內建 admission controllers 的設計，採用在 Namespace 上標記作為設定手段，後續再藉由 \ref{sec:provisioner} 權限開通設定此白名單。
 
-\section{權限開通實做}
+\section{權限開通實作}
 \label{sec:provisioner}
 
 使用者權限開通的主要流程為：建立一個 Namespace，增加 admission controllers 政策相關標記，對其設定資源配額，最終調整 RBAC 授予使用者此 Namespace 下的權限。為了將其自動化，我們規劃為拓展 Kubernetes API，使用自訂 resource 種類進行實做，此種類稱為 User。使用者登入網頁界面時會自動嘗試創立代表自身的 User，若已存在代表已開通完成不須另外動作，而面對新創立的 User，我們撰寫的 controller 會實行上述的開通流程。


@@ 115,7 115,7 @@ Kubernetes 中容器 images 的下載策略（\verb|imagePullPolicy| 欄位）
     \caption{權限開通自訂 resource 種類 User spec 範例}
 \end{figure}
 
-每個使用者會創立一個與其系計中帳號名稱相同的 User，其中 \verb|spec| 的 \verb|profile| 欄位帶有身份組資訊，影響資源配額的大小，由網頁界面自動判斷填入。對於創立代表自身 User 所需的權限，我們透過 RBAC 允許所有使用者創立 User，再透過 admission control 將其限制名稱必須與身份相同。兩階段的設計有助於簡化 RBAC 實做，使 RBAC 實做上不須枚舉使用者名稱一一事先對應，同時也大幅降低叢集上相關設定的 resources 個數，有助於減少管理上的負擔。對於 \verb|profile| 欄位的真實性，我們一樣透過 admission control 與身份資訊比對證實。
+每個使用者會創立一個與其系計中帳號名稱相同的 User，其中 \verb|spec| 的 \verb|profile| 欄位帶有身份組資訊，影響資源配額的大小，由網頁界面自動判斷填入。對於創立代表自身 User 所需的權限，我們透過 RBAC 允許所有使用者創立 User，再透過 admission control 將其限制名稱必須與身份相同。兩階段的設計有助於簡化 RBAC 實作，使 RBAC 實作上不須枚舉使用者名稱一一事先對應，同時也大幅降低叢集上相關設定的 resources 個數，有助於減少管理上的負擔。對於 \verb|profile| 欄位的真實性，我們一樣透過 admission control 與身份資訊比對證實。
 
 \begin{figure}[htb]
     \centering


@@ 125,9 125,9 @@ Kubernetes 中容器 images 的下載策略（\verb|imagePullPolicy| 欄位）
 
 就 \verb|profile| 欄位而言，還有另一個可行的方法，即是以 mutating admission control 由叢集端判斷寫入，而不仰賴網頁界面邏輯。這個方式目前有個缺點：admission control 邏輯我們希望透過 CEL 實做，而以 CEL 實做 mutating 相關機制尚未開發完成。另外，透過網頁界面預填也使得 admission control 層只須實做 validating，相對於 mutating，validating 因不能修改 resource 內容，較為單純且有平行化處理的空間，在效能與管理上皆有些許優勢。
 
-對於管理需求，我們在 admission control 實做保留了彈性，若操作者為管理者即不加以限制。管理者可以自行創立代表他人的 User，為其修改身份組，提供人工處理政策上例外的空間。另外，由 User 所產生的每個 resource 皆會採用 Kubernetes 的 \verb|ownerReferences| 機制。\verb|ownerReferences| 表現了一個 resource 被一個 owner resource 所管轄，當 owner resource 被刪除時，Kubernetes 的回收機制也會一併刪除此 resource。在我們的場景，由於使用者的資料皆為於個人專屬的 Namespace 底下，而 User 又為此 Namespace 的 owner resource，於是當使用者行為極端異常，管理者需要對其制裁時，只須刪除其 User 便可徹底清除此使用者的所作所為。
+對於管理需求，我們在 admission control 實作保留了彈性，若操作者為管理者即不加以限制。管理者可以自行創立代表他人的 User，為其修改身份組，提供人工處理政策上例外的空間。另外，由 User 所產生的每個 resource 皆會採用 Kubernetes 的 \verb|ownerReferences| 機制。\verb|ownerReferences| 表現了一個 resource 被一個 owner resource 所管轄，當 owner resource 被刪除時，Kubernetes 的回收機制也會一併刪除此 resource。在我們的場景，由於使用者的資料皆為於個人專屬的 Namespace 底下，而 User 又為此 Namespace 的 owner resource，於是當使用者行為極端異常，管理者需要對其制裁時，只須刪除其 User 便可徹底清除此使用者的所作所為。
 
-在實做方面，User 種類的定義以及 controller 邏輯採用 Kubebuilder\cite{kubebuilder} 框架撰寫。Kubebuilder 採用 Go 程式語言與 \verb|sig.k8s.io/controller-runtime| 函式庫開發，由 Go 語言的資料結構定義輔以註解補充，搭配程式碼生成技術實現 Kubernetes resource 種類的定義，並且提供實做 controller 時所需的監控 resources 變更等基本邏輯。另外，\verb|sig.k8s.io/controller-runtime| 亦具備 \verb|envtest| 測試框架，實做 kube-apiserver 等元件的自動運行，在不需要架設完整叢集的前提下，提供 controller 較為完整的測試環境。
+在實作方面，User 種類的定義以及 controller 邏輯採用 Kubebuilder\cite{kubebuilder} 框架撰寫。Kubebuilder 採用 Go 程式語言與 \verb|sig.k8s.io/controller-runtime| 函式庫開發，由 Go 語言的資料結構定義輔以註解補充，搭配程式碼生成技術實現 Kubernetes resource 種類的定義，並且提供實做 controller 時所需的監控 resources 變更等基本邏輯。另外，\verb|sig.k8s.io/controller-runtime| 亦具備 \verb|envtest| 測試框架，實做 kube-apiserver 等元件的自動運行，在不需要架設完整叢集的前提下，提供 controller 較為完整的測試環境。
 
 \subsection{Namespace}
 


@@ 159,7 159,7 @@ ResourceQuota 所能管控的資源大致有兩種：運算資源以及 resource
 
 相對於一般用途的 Kubernetes 叢集，CSKloud 也需要額外進行如啟用特定 admission controller 等設定。高層次的行為測試雖然可以直觀地撰寫，對於失敗的除錯卻需要對系統有相當深入的認知。對此，我們也撰寫叢集設定驗證測試，確保相關功能有被啟用，且其設定有經過儲存，以底層的角度防止安裝上的人為疏失。
 
-\section{網頁界面實做}
+\section{網頁界面實作}
 
 進一步對網頁界面的需求分析，可以將網頁界面切分為兩大塊：支援 Helm 的通用 Kubernetes 網頁型客戶端，以及 CSKloud 特定的部份，包含權限開通元件的整合以及 CSKloud 平台面向使用者的文件等。其中 Kubernetes 客戶端很容易的就可以利用於其他場景，我們採取 open-core\cite{hall2016open} 的策略，將其開放原始碼，以 MIT 授權條款\footnote{MIT license: 一個在網頁技術場域廣受歡迎的寬鬆型開放原始碼條款。}釋出，命名為 Sparkles\footnote{Sparkles 釋出於 \url{https://github.com/xdavidwu/sparkles} 。}，回饋於社會，使得非平台使用者也能受益，同時也利用開放原始碼社群的力量來茁壯平台的發展。
 


@@ 210,19 210,19 @@ Pods 作為 Kubernetes 中的重要角色之一，表示叢集上運行的容器
 % 或許可以來個架構圖, 沒有很重要但文字偏抽象, 要避免牽扯到前面都沒提的 kubernetes components
 有了雙向的資料流，我們還需要一個終端機模擬器負責進一步的處理，與叢集上的 pty\footnote{pty: Unix-like 系統常見的元件，主要負責處理文字行編輯、訊號快捷鍵（如 Ctrl+C）等。} 溝通。終端機模擬器繪製整個文字界面，並且處理 pty 輸出中的控制訊息，達到文字界面的顏色與游標位置等的控制。這部份我們使用既有的 Xterm.js 開源函式庫達成。
 
-\subsection{Helm 頁面與 Helm 實做}
+\subsection{Helm 頁面與 Helm 實作}
 \label{sec:helm}
 
 對於 Helm 功能，我們希望保持 SPA 架構中，將部份邏輯推往瀏覽器端在運行成本上的優勢，規劃將其在瀏覽器內實做。起初我們將 Helm 的函式庫直接透過 WebAssembly 包裝，並提供其以指令操作為切分單位的函式接口與 TypeScript 串接，但我們發現以此方式實做效能不佳，於列出已安裝的 Helm Releases 等基本操作，在低資料量下已產生足以影響使用者體驗的延遲。
 
-Helm Release 預設的 Secret 儲存方式需要經過 Base64\footnote{Base64: 一個編碼格式，可將任何形式資料轉為文字表示。} 與 gzip\footnote{gzip: 一個被廣泛利用的資料壓縮演算法。} 等操作，如果將 Helm Release 的解讀透過 WebAssembly 處理，在不經調整的情況下，呼叫的是來自 Go 語言基本函式庫的 Base64 與 gzip 實做。WebAssembly 雖然已經較為接近硬體，但設計上仍有些許限制，以及於瀏覽器場景即時編譯成原生指令迫於時間壓力無法進行較耗時的最佳化，導致效能與原生程式還是有落差\cite{jangda2019not}。而 Base64 與 gzip 作為常用的算法，瀏覽器本身有提供高效能的原生實做，在此情景卻未被利用。另外將資料傳送進出 WebAssembly 環境也有一定的執行成本。
+Helm Release 預設的 Secret 儲存方式需要經過 Base64\footnote{Base64: 一個編碼格式，可將任何形式資料轉為文字表示。} 與 gzip\footnote{gzip: 一個被廣泛利用的資料壓縮演算法。} 等操作，如果將 Helm Release 的解讀透過 WebAssembly 處理，在不經調整的情況下，呼叫的是來自 Go 語言基本函式庫的 Base64 與 gzip 實作。WebAssembly 雖然已經較為接近硬體，但設計上仍有些許限制，以及於瀏覽器場景即時編譯成原生指令迫於時間壓力無法進行較耗時的最佳化，導致效能與原生程式還是有落差\cite{jangda2019not}。而 Base64 與 gzip 作為常用的算法，瀏覽器本身有提供高效能的原生實作，在此情景卻未被利用。另外將資料傳送進出 WebAssembly 環境也有一定的執行成本。
 
-關於這個情景，我們面臨兩個可能的解法：抽換相關演算法改為呼叫瀏覽器的實做，或者將容易影響使用者體驗的區塊以 TypeScript 重新實做。抽換的方法不但無法避免資料傳輸的負擔，反而會增加傳送的次數，不甚理想。而分析 Helm 架構可發現，除了模板引擎因基於 Go 基本函式庫的模板框架，設計容易牽涉語言特性而不易重新實做外，剩餘的區塊皆為一般的資料處理與 Kubernetes API 的串接。其中需要模板引擎的操作只有安裝、升級等使用者傾向預期需要時間的情景，不包含對使用者體驗影響重大的列出 Helm Releases。綜上考量，我們將 Helm 模板引擎外的部份抽離，由 TypeScript 重新實做。
+關於這個情景，我們面臨兩個可能的解法：抽換相關演算法改為呼叫瀏覽器的實作，或者將容易影響使用者體驗的區塊以 TypeScript 重新實做。抽換的方法不但無法避免資料傳輸的負擔，反而會增加傳送的次數，不甚理想。而分析 Helm 架構可發現，除了模板引擎因基於 Go 基本函式庫的模板框架，設計容易牽涉語言特性而不易重新實做外，剩餘的區塊皆為一般的資料處理與 Kubernetes API 的串接。其中需要模板引擎的操作只有安裝、升級等使用者傾向預期需要時間的情景，不包含對使用者體驗影響重大的列出 Helm Releases。綜上考量，我們將 Helm 模板引擎外的部份抽離，由 TypeScript 重新實做。
 
 \begin{figure}[htb]
     \centering
     \includegraphics[width=\textwidth]{assets/web-helm-impl.png}
-    \caption{CSKloud v3 網頁界面實做 Helm 原理示意圖}
+    \caption{CSKloud v3 網頁界面實作 Helm 原理示意圖}
 \end{figure}
 
 除此之外，瀏覽器一般以單一執行緒運行程式碼，不論 JavaScript 或 WebAssembly 邏輯皆是在與畫面繪製相同的執行緒執行，唯 JavaScript 語言上具有異步 IO 相關設計，使得一般負擔主要在 IO 與事件處理的網頁程式碼具備可接受的效能。但我們的場景不同，Helm 的模板引擎運算量較多，在執行時容易拖累到畫面繪製，造成卡頓。對此，我們進一步採用 Web Workers 技術。Web Workers 提供一個較侷限的執行環境，但在獨立的執行緒運行，可以避面上述影響繪製的窘境，使用上開發者需自行處理 Web Workers 與瀏覽器一般執行緒間的溝通。我們將安裝、升級、回滾、解除安裝的耗時的操作，包含 WebAssembly 的使用，在 Web Workers 環境下實做以改善使用者體驗。


@@ 273,7 273,7 @@ Helm Release 預設的 Secret 儲存方式需要經過 Base64\footnote{Base64: 
 
 此頁面針對平台透過 ResourceQuota 對 Namespace 下實行的資源配額進行視覺化，使用圓餅圖顯示每個取用單位（如 Pod 下的一個容器）在相關資源（如記憶體）允許配額下所佔用的比例。使用者可以透過將游標移動到圓餅區塊上，查看取用單位的名稱以及佔用量，方便使用者了解何處取用最多。在總取用比例高到一定程度時，會改以黃色或紅色顯示提醒使用者注意。
 
-在實做上，由於 ResourceQuota 只帶有配額與佔用總量資訊，須以程式邏輯額外列舉相關 resources，解析取用單位資訊以判斷細項。另外，圓餅圖的繪製透過 Chart.js 開源函式庫實做。
+在實作上，由於 ResourceQuota 只帶有配額與佔用總量資訊，須以程式邏輯額外列舉相關 resources，解析取用單位資訊以判斷細項。另外，圓餅圖的繪製透過 Chart.js 開源函式庫實做。
 
 \subsection{Tokens 管理}
 \label{sec:tokens-mgmt}

@@ 5,7 5,7 @@
 
 我們開發出了一個採用 Namespace 作為多租戶基礎的 Kubernetes-as-a-Service 平台，針對硬多租戶模型，並且面向以有限硬體資源容納大量低用量租戶的場景設計，有著低運算負擔，但仍保持一定安全性的特色。平台帶有域名使用權管控機制，著重但不限於網頁服務的代管。
 
-根據此類平台常見的網頁形式界面需求，我們開發出了通用的 Kubernetes 客戶端，再針對平台特性提供特定功能整合以便使用，並將其成果開源釋出，即使非平台使用者，仍能從其獲益。而對於平台的多租戶實做以及相關加固，我們也透過現代技術，針對管理自動化以及減少未來維運負擔設計。另外由於硬體資源配給以及相關維運規劃等尚待進一步實行，平台尚未對外開放使用，但已經於系計中對內測試，由 PSSUQ 問卷評估，達到相當正面的反饋。
+根據此類平台常見的網頁形式界面需求，我們開發出了通用的 Kubernetes 客戶端，再針對平台特性提供特定功能整合以便使用，並將其成果開源釋出，即使非平台使用者，仍能從其獲益。而對於平台的多租戶實作以及相關加固，我們也透過現代技術，針對管理自動化以及減少未來維運負擔設計。另外由於硬體資源配給以及相關維運規劃等尚待進一步實行，平台尚未對外開放使用，但已經於系計中對內測試，由 PSSUQ 問卷評估，達到相當正面的反饋。
 
 \section{未來展望}
 


@@ 15,23 15,23 @@
 
 在 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 實做。
+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 種類。
+然而 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 的政策定義，我們可以針對平台需求修改為更加嚴格的政策。
+這類型的方法大多牽涉調整 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 額外加固則是需要對系統運作與典型工作負載有相當深入的理解，在開發上的負擔不容小覷。面對如此多元的解決方案，我們需要進一步實驗進行權衡，在成本與安全性中找尋平衡點。將系統正式上線、對平台需求規模有更明確深入的認知也將有助於這方面的分析。
+修改 CRI 實作的方案對於實際容器運行皆會增加運算負擔，甚至牽涉虛擬化技術，一定程度的降低容器在資源運用上的優勢\cite{espe2020performance}\cite{viktorsson2020security}。而對於 CRI 額外加固則是需要對系統運作與典型工作負載有相當深入的理解，在開發上的負擔不容小覷。面對如此多元的解決方案，我們需要進一步實驗進行權衡，在成本與安全性中找尋平衡點。將系統正式上線、對平台需求規模有更明確深入的認知也將有助於這方面的分析。
 
 \subsection{Control plane 虛擬化}
 
 本研究設計的平台在通用性的侷限來自於共用叢集的架構設計，需透過權限切分容納多個租戶，導致租戶無法存取叢集的完整功能，其中最大的影響是使用者無法自行註冊對 Kubernetes API 的拓展。近期除了以 Helm Charts 交付軟體產品外，也逐漸流行以 operator pattern 另外開發 operator，自動化更為複雜的軟體部屬場景。無法自行拓展 Kubernetes API 也導致了使用者無法安裝這類型的產品。
 
-一個可能的解法是管理員先行安裝常見的 operators，搭配設定 RBAC 使得使用者仍然可以由其部屬軟體，但 operators 採取能夠控制整個叢集相關 resources 的權限運行，需要嚴格審視其設計實做的安全性，避免使用者經由 operators 達成提權，在管理上潛藏著不小的負擔。若管理員不熟悉單叢集多租戶設計，更容易忽略此類攻擊路徑。
+一個可能的解法是管理員先行安裝常見的 operators，搭配設定 RBAC 使得使用者仍然可以由其部屬軟體，但 operators 採取能夠控制整個叢集相關 resources 的權限運行，需要嚴格審視其設計實作的安全性，避免使用者經由 operators 達成提權，在管理上潛藏著不小的負擔。若管理員不熟悉單叢集多租戶設計，更容易忽略此類攻擊路徑。
 
 另一個可能的想法是貫徹 control plane 與 worker nodes 的切分概念，將 control plane 進一步進行虛擬化，使得每個租戶皆有專屬的完整虛擬 control plane，能夠存取更完整的 Kubernetes 功能，而實際 worker nodes 節點仍為共用，比多個完整叢集具備較少的資源負擔\cite{zheng2021multi}。然而系計中此前未有類似需求，對於 control plane 虛擬化相當陌生，需要更多實驗來了解其維運成本。