From e3b973c0aaff60e27170e48a51727d24cf285494 Mon Sep 17 00:00:00 2001 From: Pinghao Wu Date: Wed, 25 Sep 2024 16:52:19 +0800 Subject: [PATCH] unify ref styles --- Sections/2.Backgrounds.tex | 6 +- Sections/4.Architecture.tex | 4 +- ref.bib | 139 +++++++++++++++++++++++------------- 3 files changed, 95 insertions(+), 54 deletions(-) diff --git a/Sections/2.Backgrounds.tex b/Sections/2.Backgrounds.tex index 6010da0..4c1c843 100644 --- a/Sections/2.Backgrounds.tex +++ b/Sections/2.Backgrounds.tex @@ -35,15 +35,15 @@ Kubernetes resources 的種類形成了既定的語意和格式，例如：Pod Kubernetes 提供多個身份驗證手段，可搭配混合使用，在設計上盡量單獨以驗證手段提供完整身份資訊，包含身份名稱以及所在的群組等，叢集本身以不存放身份對應的資料為原則。這樣的設計使得伺服器負擔減少，同時具有架構單純、易於除錯等優勢，但根據手段不同，可能會使得更動身份資訊（如修改所在的群組）顯得不便。常見的驗證手段主要有：X.509 憑證、authenticating proxy、static tokens、webhook tokens、ServiceAccount tokens 與 OpenID Connect tokens。 -Kubernetes 中的 X.509 憑證即為 TLS 客戶端憑證 (client certificate)，在 TLS 的驗證模型下，除了伺服器端需要提供憑證證明本身的真實性以外，客戶端也可以提供憑證，使伺服器端得以驗證客戶端的身份 (client certificate authentication, CCA)。此機制近期又以 mutual TLS (mTLS) 的名稱流行，強調雙方都可以驗證彼此的身份。Kubernetes 將身份名稱與所在群組存放在客戶端憑證的 Subject 屬性內，並且要求憑證來自特定的簽發單位 (certificate authority, CA)，通常直接由叢集管理，藉此確保資訊的真實性。雖然 X.509 標準有定義憑證的撤銷機制\cite{cooper2008internet}\cite{santesson2013x}，但目前 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 以表達使用者身份。對於代理伺服器驗證使用者的方式並沒有限制。這個方法等同於將驗證邏輯直接抽出另外自行實做，相當富有彈性，但開發成本較高，並且需自行注意撤銷等機制是否完善。 其餘的手段皆是透過 token 進行身份驗證，但 token 本身有所不同。Static tokens 是在 Kubernetes 本身預先設定好一個 token 對應身份資訊的清單，token 本身通常採用一個隨機的字串。由於目前更動這份清單需要重新啟動 kube-apiserver，這個方法較少叢集採用。Webhook tokens 則是透過管理者提供的 HTTP API 將 token 對應到身份資訊，比 static tokens 來的有彈性，可以動態更動而不須重啟 kube-apiserver。 -ServiceAccount tokens 與 OpenID Connect tokens 則皆採用 JSON Web Token (JWT)\cite{jones2015json}，一個有經過簽章的 token 格式，裡面包含身份資訊與效期等，Kubernetes 透過驗證簽章來確保真實性。ServiceAccount 是一個 resource 種類，代表一個身份，但不支援群組，由其可以簽發 ServiceAccount tokens。刪除 ServiceAccount resources 可以撤銷全部由其發出的 tokens，簽發 token 時也可以進一步綁定 Secrets\footnote{Secret: Resource 種類，提供資料儲存，本身並不帶有任何功能。} 或 Pods，使用當下會額外檢查這些 resources 是否存在，達成以 token 為單位的撤銷。由於可以透過 Kubernetes API 管理，ServiceAccount tokens 常用於自動化場景，也常用於 controllers 元件。因為 ServiceAccount tokens 採用標準的 JWT 格式，透過簽章即可確認真偽，也有自 Kubernetes 存取外部系統時，供外部系統驗證來源的應用。 +ServiceAccount tokens 與 OpenID Connect tokens 則皆採用 JSON Web Token (JWT)\cite{rfc7519}，一個有經過簽章的 token 格式，裡面包含身份資訊與效期等，Kubernetes 透過驗證簽章來確保真實性。ServiceAccount 是一個 resource 種類，代表一個身份，但不支援群組，由其可以簽發 ServiceAccount tokens。刪除 ServiceAccount resources 可以撤銷全部由其發出的 tokens，簽發 token 時也可以進一步綁定 Secrets\footnote{Secret: Resource 種類，提供資料儲存，本身並不帶有任何功能。} 或 Pods，使用當下會額外檢查這些 resources 是否存在，達成以 token 為單位的撤銷。由於可以透過 Kubernetes API 管理，ServiceAccount tokens 常用於自動化場景，也常用於 controllers 元件。因為 ServiceAccount tokens 採用標準的 JWT 格式，透過簽章即可確認真偽，也有自 Kubernetes 存取外部系統時，供外部系統驗證來源的應用。 -OpenID Connect (OIDC)\cite{sakimura2014openid} 則是一個基於 OAuth 框架衍生的身份驗證協定，廣泛運用於網頁應用場景，由中心化的伺服器進行驗證，將身份資訊授予其他應用使用，並且可以讓使用者管理對應用存取身份資料的授權。Kubernetes 本身並不實做 OIDC 協定，而是利用此機制下，OIDC 伺服器所簽發的 JWT（在協定上以 \verb|id_token| 稱呼）進行驗證，並預期由客戶端處理 OIDC 協定流程。由於可以跟現有 OIDC 伺服器整合，實做容易且不須額外的使用者註冊流程，常用於使用者的互動存取。 +OpenID Connect (OIDC)\cite{oidc} 則是一個基於 OAuth 框架衍生的身份驗證協定，廣泛運用於網頁應用場景，由中心化的伺服器進行驗證，將身份資訊授予其他應用使用，並且可以讓使用者管理對應用存取身份資料的授權。Kubernetes 本身並不實做 OIDC 協定，而是利用此機制下，OIDC 伺服器所簽發的 JWT（在協定上以 \verb|id_token| 稱呼）進行驗證，並預期由客戶端處理 OIDC 協定流程。由於可以跟現有 OIDC 伺服器整合，實做容易且不須額外的使用者註冊流程，常用於使用者的互動存取。 \begin{table}[htb] \centering diff --git a/Sections/4.Architecture.tex b/Sections/4.Architecture.tex index f3c97c3..76bc681 100644 --- a/Sections/4.Architecture.tex +++ b/Sections/4.Architecture.tex @@ -185,7 +185,7 @@ ResourceQuota 所能管控的資源大致有兩種：運算資源以及 resource Pods 作為 Kubernetes 中的重要角色之一，表示叢集上運行的容器組合，我們特別為其提供了特製一覽頁面，也展示了網頁在資料呈現與互動上的顯著優於 kubectl 的 CLI 界面。網頁界面可以很容易的繪製較複雜的表格結構，也可以透過顏色幫助使用者快速的分辨異同。同時也能夠在資料上進一步的提供互動，例如點擊容器的 image 連結會導向至相關的資訊頁面，也可以針對項目顯示功能按鈕。 -在容器的功能按鈕中，有瀏覽容器的運行紀錄 (log) 以及在容器中動態執行指令的功能。執行指令需要有雙向的即時資料流來傳送輸入與輸出，在這方面 Kubernetes 提供兩個解決方案：SPDY 與 WebSocket。SPDY 是 Google 早期提出的協定，用來改善 HTTP 1.x 的效能，如今在 HTTP 的場域已經被為廣泛的 HTTP/2 取代，Kubernetes 則是持續利用其雙向即時傳輸的功能。WebSocket\cite{fette2011websocket} 是特別設計在網頁場景提供雙向即時資料流的協定，並且連線由 HTTP 請求觸發進行進一步的協定轉移，對於 HTTP 既有的代理生態有一定的相容性而被廣泛採納。Kubernetes 原先以 SPDY 為主，因長期發展考量逐步轉換為 WebSocket。因為瀏覽器支援因素，我們採用 WebSocket 進行實做。 +在容器的功能按鈕中，有瀏覽容器的運行紀錄 (log) 以及在容器中動態執行指令的功能。執行指令需要有雙向的即時資料流來傳送輸入與輸出，在這方面 Kubernetes 提供兩個解決方案：SPDY 與 WebSocket。SPDY 是 Google 早期提出的協定，用來改善 HTTP 1.x 的效能，如今在 HTTP 的場域已經被為廣泛的 HTTP/2 取代，Kubernetes 則是持續利用其雙向即時傳輸的功能。WebSocket\cite{rfc6455} 是特別設計在網頁場景提供雙向即時資料流的協定，並且連線由 HTTP 請求觸發進行進一步的協定轉移，對於 HTTP 既有的代理生態有一定的相容性而被廣泛採納。Kubernetes 原先以 SPDY 為主，因長期發展考量逐步轉換為 WebSocket。因為瀏覽器支援因素，我們採用 WebSocket 進行實做。 % 或許可以來個架構圖, 沒有很重要但文字偏抽象, 要避免牽扯到前面都沒提的 kubernetes components 有了雙向的資料流，我們還需要一個終端機模擬器負責進一步的處理，與叢集上的 pty\footnote{pty: Unix-like 系統常見的元件，主要負責處理文字行編輯、訊號快捷鍵（如 Ctrl+C）等。} 溝通。終端機模擬器繪製整個文字界面，並且處理 pty 輸出中的控制訊息，達到文字界面的顏色與游標位置等的控制。這部份我們使用既有的 Xterm.js 開源函式庫達成。 @@ -240,7 +240,7 @@ Helm Release 預設的 Secret 儲存方式需要經過 Base64\footnote{Base64: 對於安裝的流程，按下浮動式按鈕後，會跳出對話框進行三個步驟：第一步是選擇要安裝的 Helm Chart，由一個可搜尋的列表選取。第二步是填入 Helm Values，如同 Helm CLI 以 YAML\cite{yaml}\footnote{YAML: 資料序列化語言，語法為 JSON 的超集，於 Kubernetes 常用來表達 resources。} 的形式填入，界面上提供三個頁簽，一是填寫 Helm Values 的編輯器，二是來自 Helm Chart 的 README 檔案，通常會在此提供常用選項的說明，三是 Helm Chart 內的 Helm Values 預設值檔案，慣例在此以註解的形式完整地對選項欄位說明。以 CSKloud 的場景，編輯器會自動帶入針對 CSKloud 的第二層預設值，這個預設值來自測試安裝時所帶入的參數，調整如資源配額用量等選項，以確保在平台的限制下得以安裝，使用者也可以進一步進行修改。最後的步驟則是為此 Helm Release 命名，界面會自動預設一個隨機的名字。 -調整 Helm Values 的編輯器採用 CodeMirror 開源編輯器專案，除了 YAML 的基本語法高亮以外，我們採用 codemirror-json-schema 擴充元件提供進一步的資料驗證、欄位說明與名稱自動補全。codemirror-json-schema 收取 JSON Schema 作為欄位定義，JSON Schema\cite{pezoa2016foundations} 是一個描述 JSON\cite{bray2017rfc}\footnote{JSON: 資料序列化語言，語法比 YAML 容易以程式解析。} 資料的定義框架，但由於大多數 YAML 應用場景描述的資料也都可以由 JSON 的形式表達，也常用來描述 YAML 資料。部份 Helm Chart 會提供對其 Helm Values 的 JSON Schema 定義檔。 +調整 Helm Values 的編輯器採用 CodeMirror 開源編輯器專案，除了 YAML 的基本語法高亮以外，我們採用 codemirror-json-schema 擴充元件提供進一步的資料驗證、欄位說明與名稱自動補全。codemirror-json-schema 收取 JSON Schema 作為欄位定義，JSON Schema\cite{pezoa2016foundations} 是一個描述 JSON\cite{rfc8259}\footnote{JSON: 資料序列化語言，語法比 YAML 容易以程式解析。} 資料的定義框架，但由於大多數 YAML 應用場景描述的資料也都可以由 JSON 的形式表達，也常用來描述 YAML 資料。部份 Helm Chart 會提供對其 Helm Values 的 JSON Schema 定義檔。 \subsection{Quotas 視覺化} diff --git a/ref.bib b/ref.bib index 96cc54c..78afd4d 100644 --- a/ref.bib +++ b/ref.bib @@ -2,7 +2,7 @@ title = {基於 {Kubernetes} 個別用戶資源管控之 {PaaS} 平台}, author = {周詳}, year = {2021}, - month = {January}, + month = jan, school = {國立交通大學}, type = {Master's thesis}, } @@ -11,24 +11,23 @@ title = {基於 {Kubernetes} 使用者專案管理之 {PaaS} 平台}, author = {李宗緯}, year = {2022}, - month = {August}, + month = aug, school = {國立陽明交通大學}, type = {Master's thesis}, } -% XXX quotes missing on online/electornic in IEEEtran % TODO dot position, urldate, unify rfcs -@online{kubernetes, - title = {``{Kubernetes}''}, +@misc{kubernetes, + title = {{Kubernetes}}, author = {{The Kubernetes Authors}}, year = {2024}, url = {https://kubernetes.io/}, urldate = {2024-09-23}, } -@online{helm, - title = {``{Helm}''}, +@misc{helm, + title = {{Helm}}, author = {{Helm Authors}}, year = {2024}, url = {https://helm.sh/}, @@ -43,50 +42,66 @@ year = {2017}, } -@online{cel, - title = {``{CEL}''}, +@misc{cel, + title = {{CEL}}, author = {{Google LLC}}, year = {2024}, url = {https://cel.dev/}, urldate = {2024-09-24}, } -@online{kubebuilder, - title = {``{Introduction} - The {Kubebuilder} Book''}, +@misc{kubebuilder, + title = {{Introduction} - The {Kubebuilder} Book}, author = {{The Kubernetes Authors}}, year = {2024}, url = {https://book.kubebuilder.io/introduction}, urldate = {2024-09-23}, } -@online{vue, - title = {``{Vue.js} - The Progressive {JavaScript} Framework''}, +@misc{vue, + title = {{Vue.js} - The Progressive {JavaScript} Framework}, author = {Evan You}, year = {2024}, url = {https://vuejs.org/}, urldate = {2024-09-23}, } -@techreport{fette2011websocket, - title = {The {WebSocket} protocol}, - author = {Fette, Ian and Melnikov, Alexey}, - year = {2011}, -} - -@article{jones2015json, - title = {{JSON Web Token (JWT)}}, - author = {Jones, Michael}, - journal = {Internet Engineering Task Force (IETF) RFC}, - volume = {7519}, - year = {2015}, -} - -@article{sakimura2014openid, - title = {{OpenID Connect Core} 1.0 incorporating errata set 1}, +@misc{rfc6455, + series = {Request for Comments}, + number = 6455, + howpublished = {RFC 6455}, + publisher = {RFC Editor}, + doi = {10.17487/RFC6455}, + url = {https://www.rfc-editor.org/info/rfc6455}, + author = {Alexey Melnikov and Ian Fette}, + title = {{The WebSocket Protocol}}, + pagetotal = 71, + year = 2011, + month = dec, + abstract = {The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or \textless{}iframe\textgreater{}s and long polling). {[}STANDARDS-TRACK{]}}, +} + +@misc{rfc7519, + series = {Request for Comments}, + number = 7519, + howpublished = {RFC 7519}, + publisher = {RFC Editor}, + doi = {10.17487/RFC7519}, + url = {https://www.rfc-editor.org/info/rfc7519}, + author = {Michael B. Jones and John Bradley and Nat Sakimura}, + title = {{JSON Web Token (JWT)}}, + pagetotal = 30, + year = 2015, + month = may, + abstract = {JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.}, +} + +@misc{oidc, + title = {{OpenID Connect Core} 1.0 incorporating errata set 2}, author = {Sakimura, Nat and Bradley, John and Jones, Mike and De Medeiros, Breno and Mortimore, Chuck}, - journal = {The OpenID Foundation, specification}, - volume = {335}, - year = {2014}, + year = {2023}, + url = {https://openid.net/specs/openid-connect-core-1_0.html}, + urldate = {2024-09-23}, } @inproceedings{swaminathan2011low, @@ -98,16 +113,34 @@ organization = {IEEE}, } -@techreport{cooper2008internet, - title = {Internet {X.509} public key infrastructure certificate and certificate revocation list {(CRL)} profile}, - author = {Cooper, David and Santesson, Stefan and Farrell, Stephen and Boeyen, Sharon and Housley, Russell and Polk, William}, - year = {2008}, -} - -@techreport{santesson2013x, - title = {{X.509} {Internet} public key infrastructure online certificate status protocol - {OCSP}}, - author = {Santesson, Stefan and Myers, Michael and Ankney, Rich and Malpani, Ambarish and Galperin, Slava and Adams, Carlisle}, - year = {2013}, +@misc{rfc5280, + series = {Request for Comments}, + number = 5280, + howpublished = {RFC 5280}, + publisher = {RFC Editor}, + doi = {10.17487/RFC5280}, + url = {https://www.rfc-editor.org/info/rfc5280}, + author = {Sharon Boeyen and Stefan Santesson and Tim Polk and Russ Housley and Stephen Farrell and David Cooper}, + title = {{Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile}}, + pagetotal = 151, + year = 2008, + month = may, + abstract = {This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. {[}STANDARDS-TRACK{]}}, +} + +@misc{rfc6960, + series = {Request for Comments}, + number = 6960, + howpublished = {RFC 6960}, + publisher = {RFC Editor}, + doi = {10.17487/RFC6960}, + url = {https://www.rfc-editor.org/info/rfc6960}, + author = {Stefan Santesson and Michael Myers and Rich Ankney and Ambarish Malpani and Slava Galperin and Dr. Carlisle Adams}, + title = {{X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP}}, + pagetotal = 41, + year = 2013, + month = jun, + abstract = {This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912.}, } @inproceedings{spies2021evaluation, @@ -129,7 +162,7 @@ publisher = {HeinOnline}, } -@online{openapi, +@misc{openapi, title = {{OpenAPI} Specification v3.0.0}, author = {Whitlock, Jeremy and Gardiner, Marsh and Ratovsky, Ron and Tam, Tony and Harmon, Jason}, year = {2017}, @@ -145,7 +178,7 @@ year = {2016}, } -@online{yaml, +@misc{yaml, title = {{YAML} ain't markup language {(YAML™)} version 1.2, revision 1.2.2}, author = {Ben-Kiki, Oren and Evans, Clark and döt Net, Ingy}, year = {2021}, @@ -153,9 +186,17 @@ urldate = {2024-09-25}, } -@misc{bray2017rfc, - title = {{RFC} 8259: The {JavaScript} object notation {(JSON)} data interchange format}, - author = {Bray, Tim}, - year = {2017}, - publisher = {RFC Editor}, +@misc{rfc8259, + series = {Request for Comments}, + number = 8259, + howpublished = {RFC 8259}, + publisher = {RFC Editor}, + doi = {10.17487/RFC8259}, + url = {https://www.rfc-editor.org/info/rfc8259}, + author = {Tim Bray}, + title = {{The JavaScript Object Notation (JSON) Data Interchange Format}}, + pagetotal = 16, + year = 2017, + month = dec, + abstract = {JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.}, } -- 2.45.2