?盡管Kubernetes是當今使用最廣泛的開源容器編排平臺，但它沒有創建和管理用戶的手段，至少沒有本地方式。然而，這并不是一個缺點，因為它可以對接多種認證服務。也正因此，Dex已成為Kubernetes可用的最佳身份驗證解決方案之一。

在本文中，您將了解有關 Dex for Kubernetes 的更多信息。我們將探討它可以解決的一些問題，通過使用第三方身份提供者進行設置的高級概述，并考慮 Dex 未涵蓋的一些仍需要解決的問題。

什么是Dex？

Dex是 CoreOS, Inc. 發布的開源 CNCF 沙箱項目和身份驗證服務，它使用 OpenID Connect (OIDC) 將 Kubernetes 和其他與 OIDC 兼容的服務與無數身份提供者鏈接。換句話說，您可以將 Dex 視為kubectl Okta、GitHub、Google、Microsoft 和 Linkedin 等廣泛使用的身份提供商之間的中介。

Dex 作為 Kubernetes 和其他身份提供者之間的橋梁的能力允許管理員實施集中的用戶和組管理，這對于擁有多個團隊的組織來說是必不可少的。

此外，正如您將在以下部分中了解的那樣，Dex 還可以加強安全性，并為 Kubernetes 帶來現代便捷的登錄體驗。

Dex for Kubernetes 是如何工作的？

在深入了解 Dex 的工作原理之前，了解 Kubernetes 身份驗證過程的工作原理非常重要。

與 Kubernetes 集群通信時，kubectl?實際上是在與 API 服務器進行交互。對于 API 服務器的每個 HTTP 請求，身份驗證插件都會查找用戶名、UID 和組。此類屬性可以由客戶端證書、身份驗證代理或不記名令牌提供。這就是 Dex 的用武之地，充當身份提供者和kubectl客戶端之間的橋梁。

由于 Dex 使用 OIDC，它可以使用所謂的“connectors”訪問存儲在第三方身份提供商中的用戶信息。這允許 Dex 以不記名令牌的形式將用戶信息轉發給 Kubernetes 以完成身份驗證過程。所有這些對用戶都是透明的，因為它是通過單點登錄 (SSO) 流程完成的。

此外，正如我們將在下一節中討論的那樣，Dex 發送的 ID 令牌包含可用于用戶授權的信息。

上述過程是對 Kubernetes 中身份驗證工作方式的簡化。有關身份驗證過程的更多詳細信息，請查看官方Kubernetes 文檔。

(https://kubernetes.io/docs/reference/access-authn-authz/authentication/)

Dex 解決了什么問題？

我們已經提到，Dex 通過允許管理員使用組織的身份服務提供者來管理用戶和組來擴展 Kubernetes 的功能。

然而，這并不是 Dex 解決的唯一問題。讓我們來看看它提供的其他一些好處。

01提高安全性

Dex 以多種方式提高了 Kubernetes 集群的安全性：

它提供了一種通過身份提供者將用戶登錄到集群的安全方式。

它消除了與為多個用戶使用相同的 kubeconfig 文件相關的安全風險。

它可以通過審核日志有效地檢測每個用戶執行的操作。

它消除了無時間限制地創建不記名令牌的做法。

由于使用 RBAC 規則（零信任 RBAC 訪問）進行有效的用戶和組管理，它有助于執行身份驗證和授權策略。

02靈活性

每個組織都有獨特的要求，而 Dex 足夠靈活，幾乎可以使用任何身份提供者。Okta、GitHub、GitLab、Microsoft、Linkedin 以及使用 OpenID Connect、OAuth 2.0、LDAP 和 SAML 2.0 協議等的服務可用的連接器就是證明。 更多Dex的信息請操作github地址。(https://github.com/dexidp/dex)

03提供集中認證系統

實施 Dex 可能不是小型團隊的最佳解決方案。但是，對于擁有數十名用戶分布在不同團隊中的組織來說，Dex 是一個非常強大的工具。不必手動創建、管理和分發 kubeconfig 文件在節省時間和安全性方面都是一個巨大的優勢。

此外，Dex 通過實現更精細的訪問控制來補充 Kubernetes。正如您將在下一節中看到的，Dex 控制 ID 令牌的發行，允許您指定其持續時間，這對于涉及臨時用戶訪問的情況非常方便。

此外，如有必要，您可以撤銷所有 ID 令牌。您甚至可以撤銷特定用戶或組的訪問權限。

總而言之，Dex 可以讓你為 Kubernetes 添加一個高效易用的集中式認證系統。

使用 Dex 在 Kubernetes 上設置身份驗證

正如我們已經建立的那樣，Dex 充當了一個門戶，它使用連接器將 Kubernetes 與多個身份提供者鏈接起來。

下圖提供了單點登錄過程的高級概述：

在身份驗證過程中，將執行以下步驟：

1. 最終用戶發起登錄 Dex 的請求。這通常通過用戶啟動單點登錄的 Web 應用程序或門戶來完成。
2. Dex 將此請求轉發給第三方身份提供商（例如，Active Directory、Google、GitHub 或 Okta）。為此，Dex 使用“connectors”，它具有一系列用于查詢其他用戶管理系統的協議。
3. 多虧了這些“connectors”，Dex 可以從身份提供者那里訪問相關的用戶信息，例如姓名、電子郵件、唯一標識符、組、訪問令牌等。在 Okta 的情況下，這些數據以 ID 令牌的形式出現。根據Dex 文檔，“ID 令牌是 JSON Web 令牌 (JWT)……作為證明最終用戶身份的 OAuth2 響應的一部分返回。”
4. 一旦 Dex 從第三方上游身份提供者那里獲得了用戶信息，它就會承擔身份提供者的角色，并頒發一個簽名的 ID 令牌發送給kubectl客戶端，客戶端將 JWT 轉發給 API 服務器。
5. API 服務器使用 Kubernetes OpenID Connect 令牌身份驗證器插件使用 ID 令牌。此時的結果可以是驗證或拒絕用戶。如果用戶成功通過身份驗證，API 服務器將使用 ID 令牌信息來應用 RBAC 規則。
6. 來自 API 服務器的響應被發送回kubectl客戶端。
7. 客戶端將kubectl結果顯示給最終用戶。

有關通過 LDAP 進行身份驗證的信息，請閱讀此處(https://dexidp.io/docs/connectors/ldap/?) 的文檔。有關如何通過 OpenID Connect 提供程序（例如 Okta）進行身份驗證的其他信息，請參閱此處(?https://dexidp.io/docs/connectors/oidc/?) 的文檔。

Dex 沒有解決哪些問題？

盡管 Dex 為尋求 Kubernetes 單點登錄體驗的組織提供了出色的解決方案，但它也不能免除與某些身份提供者相關的限制。

正如Dex 文檔(https://github.com/dexidp/dex) 所示，并非所有身份提供者都支持刷新令牌請求。這意味著根據身份提供者的不同，用戶將不得不不時重復上一節中描述的身份驗證過程。

此外，并非所有的 Dex 連接器都是穩定的。Google、Bitbucket Cloud 和 OAuth 2.0 的連接器狀態仍為 alpha。

要記住的另一點是，Dex 僅用作身份驗證解決方案。環境變量、kube-contexts 和成本的管理必須手動完成或通過使用其他工具完成。

結論

在本文中，您了解到 Dex 是一種可行的解決方案，可以通過 Kubernetes 獲得更好的登錄體驗。

作為 OIDC 提供商，Dex 允許您的組織利用正在使用的身份提供商連接到 Kubernetes。

這是一個巨大的優勢，因為無需添加額外的基礎設施，您的組織就可以為 Kubernetes 實施集中式身份管理，從而節省時間并有助于改進安全策略。

原文： ?https://loft.sh/blog/dex-for-kubernetes-how-does-it-work/