Kubernetes實現SSO登入

無論生活還是工作，我們經常會登入各種各樣的網站，對於我來說，要記住每個網站的登入資訊簡直就像一場噩夢。

每次註冊一個新網站，我會找“使用……登入”之類的連結，希望它能直接從Google或Facebook之類的地方獲取我的註冊資訊。我發現SSO能提升使用者體驗，減少帳戶數量的同時，也節省了一天中登入的次數。

作為Pusher的雲工程師，我每天都會用Kubernetes。有一段時間，用我們的Kubernetes叢集進行身份驗證的體驗和理想中的SSO（Single Sign-On：單點登入）相差甚遠。從一開始使用Kubernetes，我們一直在用單個共享證書進行身份驗證，但我們希望每位工程師都擁有自己的憑證。為此，我試圖將Kubernetes的登入盡可能做的簡單易用，就像我登入其他網站時選擇“使用……登入”一樣。

Kubernetes很棒的一點是它的認證和授權完全分離。身份認證（Authn）是用來識別使用者是誰，授權（Authz）是用來確認是否允許執行某項操作。我們可以把兩者想象成護照和簽證。在邊境，有人檢查你的護照（Authn），確認你是誰，然後檢查你的Visa（Authz），確認你是否有權進入他們的國家。

這篇文章中，我會闡述基於Kubernetes的身份驗證，尤其是SSO的方法，但不會深入的介紹具體的配置。我會在另一篇文章[1]中介紹我們正在使用的身份驗證流程，以及如何配置。

Kubernetes支援的認證方法

Kubernetes有三種主要的身份驗證方法，用於和API進行互動。官網的一個頁面[2]列出了更多的認證方法，但以下三種是使用者認證常見的方法。

靜態密碼

也叫基本身份驗證。由於新增新使用者，需要更新每個API伺服器節點上的檔案，然後重啟每個API伺服器，因此不利於擴充套件。我們很快就排除了這種方法。

X.509客戶端證書

使用這種方法，每個開發人員都有自己的證書，在建立連線時會呈現給API伺服器。API伺服器透過驗證證書和使用證書內的資訊來識別該會話的使用者。

證書認證有幾個問題：

• 證書在簽發時有一個有效期。它們在有效期內進行使用者認證。（不使用OCSP）。

• 證書必須由一些通用證書簽發機構（CA）簽署。Kubernetes需要CA證書的副本來驗證客戶端證書。如果允許人們訪問這些CA證書進行自簽，他們就有權賦予自己任何組證書或身份。這會導致許可權升級，所以必須設法集中簽發證書。

• 簽發證書並不容易，因為證書通常有很長的使用期限。

• 在瀏覽器內（例如為Kubernetes儀錶板）進行證書認證比較困難。

雖然這個解決方案可以識別單個使用者，但不是使用者友好的方式，所以我決定找一個更簡單的方案。

OpenID Connect（OIDC）

Kubernetes用OIDC實現SSO，但目前支援OIDC的供應商屈指可數。雖然這個方案乍看令人沮喪，但它確實可以實現SSO，不用為每個人建立帳號。最終，我們團隊決定朝著這個方向繼續調查。

什麼是Open ID Connect

在Pusher內部，我們用Google的G Suite託管我們的電子郵件，如果可以構建由Google支援的單一登入，那麼每位工程師都可以使用已有的登入名。Google支援OIDC作為其平臺的一部分，所以我們決定調查OIDC以及它的工作原理。

OpenID Connect基於OAuth 2.0協議,在設計時考慮了身份認證。OIDC生成一個ID令牌。

此類ID令牌採用JSON Web令牌或JWT（發音為jot）的格式，如下所示：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

該字串由三部分組成，每個都是Base64編碼的JSON。第一部分提供令牌的元資料。第二部分提供身份資訊，即所謂的有效載荷。第三部分是簽名，用於驗證令牌是否是由可信方簽發。

如果對有效載荷進行解碼，它看起來就像這樣：

“iss”：“https://auth.pusherplatform.io/dex”，
“sub”：“ChUxMDk0MzA2MjQwNTcwNDc3MDE4MTkSBmdvb2dsZQ”，
“aud”：“kubernetes”，
“exp”：1519123284，
“iat”：1519036884，
“at_hash”：“X2G33w55vEm39VwyOMMjzg”，
“email”：“joel.speed@pusher.com”，
“email_verified”：true，
“name”：“Joel Speed”

有效載荷包含了發起OIDC登入流程的使用者身份資訊。它通常包含使用者的名字和電子郵件，但也可能包含一些額外的資訊，例如組別資訊。

OIDC生成令牌的流程類似於OAuth 2.0：

1. 使用者點選網站上的登入按鈕

2. 該網站將其重定向到身份提供商

3. 瀏覽器載入身份提供商的登入畫面

4. 使用者用他們的使用者名稱和密碼登入

5. 身份提供商將其重定向（包含查詢字串中的身份驗證碼）回原網站

6. 瀏覽器用查詢字串中的認證碼載入網站

7. 網站伺服器交換ID令牌。

伺服器獲取該令牌後，不僅可用於該使用者的身份驗證，還可為該使用者登入其它服務提供身份認證，前提是信任該身份提供商。

Kubernetes本身不提供任何型別的OIDC認證登入網站，但你可以把從其他途徑得到的令牌傳遞給它。這難免讓人感到困惑，Kubernetes和身份提供商之間的信任關係又是怎麼達成的呢？

就像之前提到過的，令牌的第三部分是簽名。OIDC提供商生成的每個ID令牌都帶有一個加密的金鑰（通常是RS256，由提供商定期生成）。Kubernetes透過OIDC提供商的URL，檢索到對應的公鑰並驗證該令牌是由OIDC提供商簽發。至此，Kubernetes接受令牌並信任該令牌代表的使用者。

OIDC的侷限性

雖然OIDC朝著“好”的使用者登入體驗邁進了一步，但它也有侷限性。

一個問題是ID令牌一旦生成就沒法撤銷。ID令牌和Auth證書一樣，有一個有效期。超過有效期，使用者就要重新認證。令牌通常簽發1小時，但一些提供商支援令牌掃清。令牌掃清（通常無限期地）可用於簽發新的ID令牌，從而保證持久使用某項服務。

另一個問題是缺少支援。Kubernetes官方檔案僅列出了三個提供商，如果你不使用Salesforce，Azure AD或Google之一，則無法體驗沒有內建的SSO服務。

Dex介紹

調查OIDC時，我偶然發現了CoreOS的這款開源產品，它著實幫我解決了一些難題。

Dex[3]在認證過程中充當中間人的角色。它是Kubernetes ID令牌的提供商和頒發者，但它本身並沒有身份認證的功能，而是透過配置上游身份提供商的方式，來提供使用者身份認證。

Dex和其他OIDC提供商一樣，支援從GitHub，GitLab，SAML，LDAP和Microsoft獲取使用者資訊。它的提供商外掛大大提高了與客戶現有的使用者管理系統進行整合的能力。

Dex的另一個優勢是能夠控制ID令牌的釋出，例如指定生命週期。它能強制組織進行重新認證。藉助Dex，可以輕鬆撤消所有令牌，但無法撤銷單個令牌。

Dex還為使用者提供令牌掃清機制。當使用者登入到Dex時，他會被授予一個ID令牌和一個掃清令牌。諸如kubectl之類的程式可以用這些掃清令牌，在ID令牌過期時重新認證使用者。由於這些令牌是Dex釋出的，因此可以透過撤銷其掃清令牌來停止特定使用者的掃清。這在膝上型電腦或手機丟失的情況下就非常有用。

此外，對於Dex這樣的集中式認證系統，只需配置一次上游提供商即可。我們有一個設定使得上游的身份提供商只知道Dex。然後，Dex利用多個客戶端，對使用內部網站和Kubernetes API的使用者進行身份驗證。

這種設定的一個好處是，任何使用者想要往SSO系統裡新增新服務，只需要在Dex配置一個PR。該設定還為使用者提供基於上游身份提供商的一鍵式“撤銷訪問”的功能，用來撤銷訪問所有內部服務的許可權。同樣，這在出現安全漏洞或膝上型電腦丟失的情況下，非常有用。

在Pusher內部，透過使用Dex作為身份認證提供商的代理，使我們對使用者身份令牌的簽發和撤銷，變得精準可控，而且，重要的是，使用者不再需要用另一個身份來管理。

總結

在重新審視我們的備選項時，我和我的團隊認為我們確實應該用OIDC作為Kubernetes的身份驗證。我們傾向於用我們的G Suite帳戶，這對我們的工程師來說，比讓他們去簽發證書容易的多。我們也喜歡Dex帶給我們的可控力，不僅是可以設定極短的令牌生命週期，而且還可以讓我們管理工程師的會話，在必要時，可以讓使用者退出叢集。

OIDC為工程師們提供友好的使用者登入體驗的同時，還可以透過RBAC的方式限制訪問。

在下一篇文章中，我將更加詳細地介紹在Pusher是如何配置特定的SSO，並深入說明使用者如何生成ID令牌，以及他們在使用命令列和Web瀏覽器進行身份驗證時的使用者體驗。同時，我也會詳細地闡述如何在你的組織中實現SSO登入。

相關連結：

1. https://thenewstack.io/tag/Kubernetes-SSO-series

2. https://kubernetes.io/docs/admin/authentication/

3. https://github.com/coreos/dex

原文連結：https://thenewstack.io/kubernetes-single-sign-one-less-identity

Kubernetes入門與進階實戰培訓

本次培訓內容包括：Docker基礎、容器技術、Docker映象、資料共享與持久化、Docker三駕馬車、Docker實踐、Kubernetes基礎、Pod基礎與進階、常用物件操作、服務發現、Helm、Kubernetes核心元件原理分析、Kubernetes服務質量保證、排程詳解與應用場景、網路、基於Kubernetes的CI/CD、基於Kubernetes的配置管理等，點選瞭解具體培訓內容。

6月22日正式上課，點選閱讀原文連結即可報名。