3 files changed, 17 insertions(+), 3 deletions(-)

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

@@ 21,6 21,6 @@
 
 綜上所述，我們需要一個網頁代管平台，除了一般平台常見的配額等管理機制外，我們希望以容器作為使用者部屬網頁的基本方式。透過此平台，我們可以集中管理系上四散的網頁服務，提高資源運用效率。另外，以容器作為形式也使得平台本身具備往其他需求發展的可行性，雖設計上以架設網頁服務為主要需求，實質上可以規劃為通用型雲端運算平台。
 
-\section{研究目的}
+\section{研究目標}
 
 對於容器的大量部屬，目前最廣泛最通用的技術為 Kubernetes。我們希望以 Kubernetes-as-a-Service 的型式，提供代管的 Kubernetes 平台，讓使用者能夠直接透過標準的 Kubernetes API 進行操作。平台將針對系上的大量多人使用需求規劃，並且雖著重於網頁服務的架設，同時也保留 Kubernetes 本身的通用性，可以作為通用的雲端運算平台使用。對於不熟悉 Kubernetes 的使用者，我們也應提供友善的網頁界面，使其也能利用平台達成一般網頁的架設。

@@ 31,7 31,21 @@ Kubernetes 提供 RESTful API 做為主要控制手段，以 resources 作為對
 
 Kubernetes resources 的種類帶給 resources 既定的語意和格式，例如：Pod 代表一組可以互通部份設定的容器、Service 代表網路上具備負載均衡的一個存取點、Node 代表叢集中的一個節點等。其中種類又分為兩大類型：namespaced 與 cluster-scoped。Namespaced 代表此種類在 API 上受到 Namespace 分隔，在不同的 Namespace 下，各個 resources 無法相互關聯，通常用於描述賦予叢集的工作 (workload)，Pod 與 Service 即為此類：Service 可以關聯到多個 Pod 提供實際服務內容，但在設計上不允許 Service 取用其他 Namespace 下的 Pod。Cluster-scoped 的種類則不受 Namespace 管轄，屬於整個叢集，常見於描述叢集本體的設定，Node 與 Namespace 本身即為此類。在使用慣例上，Namespace 用以切分不同的應用，使得無關的應用在部屬設定上不會互相衝突影響，但須注意 Namespace 僅只限制 resources 能夠描述的相互關係，並不代表會對實際運行的容器或網路進行隔離加固。
 
-% TODO maybe authn here to introduce sparkles token management later
+\subsection{Kubernetes 身份驗證}
+
+Kubernetes 的身份驗證策略採用完全以驗證手段提供身份資訊的方式，包含身份名稱以及所在的群組等。Kubernetes 原則上並不存放身份對應的資料，這樣的設計使得伺服器負擔減少，同時有架構單純、易於除錯等優勢，但根據手段不同，可能會使得修改相關資訊（如修改所在的群組）變得不便。其中面向使用者的驗證手段主要有：X.509 憑證、authenticating proxy、static tokens、webhook tokens、ServiceAccount tokens 與 OpenID Connect tokens。
+
+Kubernetes 中的 X.509 憑證即為 TLS 客戶端憑證 (client certificate)，在 TLS 的驗證模型下，除了伺服器端需要提供憑證確保伺服器端的真實性以外，客戶端也可以提供憑證，使伺服器端得以驗證客戶端的身份。此機制近期又以 mutual TLS (mTLS) 的名稱流行，強調雙方都可以驗證彼此的身份。Kubernetes 將身份名稱與所在群組存放在客戶端憑證的 Subject 屬性內，並且要求憑證來自特定（通常直接由叢集管理）的簽發單位 (certificate authority, CA)，藉此確保資訊的真實性。雖然 X.509 標準有定義憑證的撤銷機制，但目前 Kubernetes 並沒有相關實做，導致只能利用簽發短期限的憑證，達到金鑰洩漏的減災，同樣原因也使得這個方法不易修改群組資訊。由於客戶端憑證較不方便使用，尤其需要透過頻繁換發短期限憑證達到安全性，相關自動化成本較高，除了叢集內部元件的身份驗證外，較不常用於使用者端，多見於非正式環境，或是另外嚴謹保存作為管理員的備用手段。
+
+Authenticating proxy 透過在 Kubernetes API 之前加一層 proxy 伺服器進行驗證邏輯。Proxy 在將請求轉發給 Kubernetes API 時會加上相關 HTTP headers 以表明使用者身份，而 proxy 本身對使用者的認證方式並沒有限制。這個方法等同於將驗證邏輯直接抽出另外自行實做，開發成本較高，並且需自行注意如撤銷等機制的是否完善。
+
+其餘的手段皆是透過 token 進行身份驗證，但 token 本身有所不同。Static tokens 是在 Kubernetes 本身預先設定好一個 token 對應使用者名稱、所在群組的清單，token 本身通常採用一個隨機的字串。由於目前實做上更動這份清單需要重新啟動 kube-apiserver，這個方法較少人採用。Webhook tokens 則是透過管理者提供的 HTTPS API 去將 token 對應到相關資訊，比 static tokens 來的有彈性，可以動態更動不須重啟 kube-apiserver。
+
+ServiceAccount tokens 與 OpenID Connect tokens 則都是 JSON Web Token (JWT)，一個有經過簽章的 token 格式，裡面包含身份資訊與使用期限等，Kubernetes 透過驗證簽章來確保他的真實性。ServiceAccount 是一個 resources 種類，代表一個身份，但不支援群組，由此可以簽發 ServiceAccount tokens，刪除 ServiceAccount resources 可以撤銷全部由其發出的 tokens。簽發 ServiceAccount tokens 時也可以進一步綁定 Secrets 或 Pods，使用時會額外檢查這些 resources 是否存在，達成以 token 為單位的撤銷。由於可以透過 Kubernetes API 管理，ServiceAccount tokens 常用於自動化場景，也常用於 controllers 元件。由於 ServiceAccount tokens 採用標準的 JWT 格式，透過簽章即可確認真偽，也有自 Kubernetes 存取外部系統時，供外部系統驗證的應用。
+
+OpenID Connect (OIDC) 則是一個基於 OAuth 框架衍生的身份驗證協定，常用於網頁應用場景，由中心化的伺服器進行驗證，將身份資訊授予其他應用使用，並且可以讓使用者管理對應用存取身份資料的授權。Kubernetes 本身並不實做 OIDC 協定，而是利用驗證流程 OIDC 伺服器所簽發的 JWT (\verb|id_token|) 進行驗證，並預期由客戶端處理 OIDC 協定相關操作。由於可以跟現有 OIDC server 整合，實做容易且使用者不須額外的註冊流程，常用於使用者的互動存取。
+
+% 可能弄個對 revocation 和 expiration support 的比較表, 但大概要想辦法加上 renew 好不好實施(?) 去 justify 在 expiration 可以壓很短的情況下有沒有 revocation 還好
 
 \subsection{Kubernetes 存取控制}
 

@@ 9,7 9,7 @@
 
 一代系統確立了對平台的大致規劃：以 Kubernetes 提供基於容器的網頁代管服務、以 Kubernetes Namespace 在單一叢集下實施多租戶設計、串接 Kubernetes 內建資源配額機制。作者實做了透過根據由 LDAP 獲取的使用者資訊，為使用者設立 Namespace、資源配額以及以 RBAC 控管使用，並提供對平台網頁界面的設計稿，提出以 Helm 簡化使用方式的想法。在使用者驗證上，作者規劃以平台網頁界面透過串接系計中的身份驗證系統，再由網頁界面創立 token 以進行 Kubernetes API 驗證的使用流程。使用者可以根據該 token 自行存取 Kubernetes API，或者直接使用平台網頁界面存取部份功能。但由於作為身份驗證手段的網頁界面尚未實做，使用者無法進行任何操作，系統無法使用待進一步開發。另外作者指出設計上尚缺乏域名使用權的管控機制。
 
-二代系統沿襲了一代對於多租戶與資源配額的設計，另外將身份驗證以 OpenID Connect 協定（OIDC，基於 OAuth 發展的身份驗證協定）實做，發展出可運作的基本網頁界面，並實做部屬單一網頁服務，以及安裝少數特定軟體的功能，但並未如一代規劃開放使用者直接存取 Kubernetes API。對於 Kubernetes 叢集本身，二代系統指出在此基於 Namespace 的多租戶設計下，Kubernetes RBAC 驗證對於限制使用者的行為並不足夠，並且導入 admission controllers 作為加固手段，以 Open Policy Agent 框架透過 webhooks 自行實做 admission controllers 邏輯，同時也以此實做域名使用權管控機制。二代系統雖然已經可以運作，具有一定的基本功能，卻因為實做皆以概念驗證的角度撰寫，品質並不適合開放使用，導致系計中普遍對系統有安全性疑慮，並未實際上線。
+二代系統沿襲了一代對於多租戶與資源配額的設計，另外將身份驗證以 OIDC 實做，發展出可運作的基本網頁界面，並實做部屬單一網頁服務，以及安裝少數特定軟體的功能，但並未如一代規劃開放使用者直接存取 Kubernetes API。對於 Kubernetes 叢集本身，二代系統指出在此基於 Namespace 的多租戶設計下，Kubernetes RBAC 驗證對於限制使用者的行為並不足夠，並且導入 admission controllers 作為加固手段，以 Open Policy Agent 框架透過 webhooks 自行實做 admission controllers 邏輯，同時也以此實做域名使用權管控機制。二代系統雖然已經可以運作，具有一定的基本功能，卻因為實做皆以概念驗證的角度撰寫，品質並不適合開放使用，導致系計中普遍對系統有安全性疑慮，並未實際上線。
 
 在實做方面，為了簡化同時避免使用 LDAP、OIDC 兩個協定在類似的場景，二代去除了一代使用自訂 Kubernetes resources 種類實做的 LDAP 使用者開通功能，取而代之的是由網頁界面本身，在使用者首次登入時進行相關的開通。另外安裝少數特定軟體的功能實質是使用 Helm 實做，但網頁界面只提供極少數的 Charts 開放使用，並由程式邏輯產生其 Values 設定，使用者無法對安裝設定（例如資源配置等）做任何修改。由類似的方式可以將功能推廣至其他應用的安裝，以達成一代規劃藉由 Helm 簡化系統使用的願景，但需要人力為每個應用逐一撰寫產生 Values 的邏輯，過於勞力密集且十分缺乏彈性，並且尚未實做更新、回滾等功能。在部屬單一網頁服務的部份，則是採用內建的 resources 模板再針對特定欄位提供表單客製化，因此成果也容易顯的相當侷限，以這個角度設計容易帶有過多的假設，例如假定只須一個容器、假定容器提供服務的 HTTP port 等，並且沒有顧慮到如安裝資料庫等網頁服務本體外的基礎建設場景。