建站
咨詢
售后
建站咨詢
新聞中心
詳解使用Dex實現(xiàn)Kubernetes身份驗證
作者：祝祥 翻譯 2023-04-18 08:00:35
云計算
云原生 在本文中，您了解到 Dex 是一種可行的解決方案，可以通過 Kubernetes 獲得更好的登錄體驗。
創(chuàng)新互聯(lián)建站長期為1000多家客戶提供的網(wǎng)站建設服務，團隊從業(yè)經(jīng)驗10年，關注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為定興企業(yè)提供專業(yè)的網(wǎng)站建設、成都網(wǎng)站設計，定興網(wǎng)站改版等技術服務。擁有十年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。
?盡管Kubernetes是當今使用最廣泛的開源容器編排平臺，但它沒有創(chuàng)建和管理用戶的手段，至少沒有本地方式。然而，這并不是一個缺點，因為它可以對接多種認證服務。也正因此，Dex已成為Kubernetes可用的最佳身份驗證解決方案之一。
在本文中，您將了解有關 Dex for Kubernetes 的更多信息。我們將探討它可以解決的一些問題，通過使用第三方身份提供者進行設置的高級概述，并考慮 Dex 未涵蓋的一些仍需要解決的問題。
什么是Dex？
Dex是 CoreOS, Inc. 發(fā)布的開源 CNCF 沙箱項目和身份驗證服務，它使用 OpenID Connect (OIDC) 將 Kubernetes 和其他與 OIDC 兼容的服務與無數(shù)身份提供者鏈接。換句話說，您可以將 Dex 視為kubectl Okta、GitHub、Google、Microsoft 和 Linkedin 等廣泛使用的身份提供商之間的中介。
Dex 作為 Kubernetes 和其他身份提供者之間的橋梁的能力允許管理員實施集中的用戶和組管理，這對于擁有多個團隊的組織來說是必不可少的。
此外，正如您將在以下部分中了解的那樣，Dex 還可以加強安全性，并為 Kubernetes 帶來現(xiàn)代便捷的登錄體驗。
Dex for Kubernetes 是如何工作的？
在深入了解 Dex 的工作原理之前，了解 Kubernetes 身份驗證過程的工作原理非常重要。
與 Kubernetes 集群通信時，kubectl?實際上是在與 API 服務器進行交互。對于 API 服務器的每個 HTTP 請求，身份驗證插件都會查找用戶名、UID 和組。此類屬性可以由客戶端證書、身份驗證代理或不記名令牌提供。這就是 Dex 的用武之地，充當身份提供者和kubectl客戶端之間的橋梁。
由于 Dex 使用 OIDC，它可以使用所謂的“connectors”訪問存儲在第三方身份提供商中的用戶信息。這允許 Dex 以不記名令牌的形式將用戶信息轉發(fā)給 Kubernetes 以完成身份驗證過程。所有這些對用戶都是透明的，因為它是通過單點登錄 (SSO) 流程完成的。
此外，正如我們將在下一節(jié)中討論的那樣，Dex 發(fā)送的 ID 令牌包含可用于用戶授權的信息。
上述過程是對 Kubernetes 中身份驗證工作方式的簡化。有關身份驗證過程的更多詳細信息，請查看官方Kubernetes 文檔。
(https://kubernetes.io/docs/reference/access-authn-authz/authentication/)
Dex 解決了什么問題？
我們已經(jīng)提到，Dex 通過允許管理員使用組織的身份服務提供者來管理用戶和組來擴展 Kubernetes 的功能。
然而，這并不是 Dex 解決的唯一問題。讓我們來看看它提供的其他一些好處。
01提高安全性
Dex 以多種方式提高了 Kubernetes 集群的安全性：
它提供了一種通過身份提供者將用戶登錄到集群的安全方式。
它消除了與為多個用戶使用相同的 kubeconfig 文件相關的安全風險。
它可以通過審核日志有效地檢測每個用戶執(zhí)行的操作。
它消除了無時間限制地創(chuàng)建不記名令牌的做法。
由于使用 RBAC 規(guī)則（零信任 RBAC 訪問）進行有效的用戶和組管理，它有助于執(zhí)行身份驗證和授權策略。
02靈活性
每個組織都有獨特的要求，而 Dex 足夠靈活，幾乎可以使用任何身份提供者。Okta、GitHub、GitLab、Microsoft、Linkedin 以及使用 OpenID Connect、OAuth 2.0、LDAP 和 SAML 2.0 協(xié)議等的服務可用的連接器就是證明。 更多Dex的信息請操作github地址。(https://github.com/dexidp/dex)
03提供集中認證系統(tǒng)
實施 Dex 可能不是小型團隊的最佳解決方案。但是，對于擁有數(shù)十名用戶分布在不同團隊中的組織來說，Dex 是一個非常強大的工具。不必手動創(chuàng)建、管理和分發(fā) kubeconfig 文件在節(jié)省時間和安全性方面都是一個巨大的優(yōu)勢。
此外，Dex 通過實現(xiàn)更精細的訪問控制來補充 Kubernetes。正如您將在下一節(jié)中看到的，Dex 控制 ID 令牌的發(fā)行，允許您指定其持續(xù)時間，這對于涉及臨時用戶訪問的情況非常方便。
此外，如有必要，您可以撤銷所有 ID 令牌。您甚至可以撤銷特定用戶或組的訪問權限。
總而言之，Dex 可以讓你為 Kubernetes 添加一個高效易用的集中式認證系統(tǒng)。
使用 Dex 在 Kubernetes 上設置身份驗證
正如我們已經(jīng)建立的那樣，Dex 充當了一個門戶，它使用連接器將 Kubernetes 與多個身份提供者鏈接起來。
下圖提供了單點登錄過程的高級概述：
在身份驗證過程中，將執(zhí)行以下步驟：
- 最終用戶發(fā)起登錄 Dex 的請求。這通常通過用戶啟動單點登錄的 Web 應用程序或門戶來完成。
- Dex 將此請求轉發(fā)給第三方身份提供商（例如，Active Directory、Google、GitHub 或 Okta）。為此，Dex 使用“connectors”，它具有一系列用于查詢其他用戶管理系統(tǒng)的協(xié)議。
- 多虧了這些“connectors”，Dex 可以從身份提供者那里訪問相關的用戶信息，例如姓名、電子郵件、唯一標識符、組、訪問令牌等。在 Okta 的情況下，這些數(shù)據(jù)以 ID 令牌的形式出現(xiàn)。根據(jù)Dex 文檔，“ID 令牌是 JSON Web 令牌 (JWT)……作為證明最終用戶身份的 OAuth2 響應的一部分返回?！?/li>
- 一旦 Dex 從第三方上游身份提供者那里獲得了用戶信息，它就會承擔身份提供者的角色，并頒發(fā)一個簽名的 ID 令牌發(fā)送給kubectl客戶端，客戶端將 JWT 轉發(fā)給 API 服務器。
- API 服務器使用 Kubernetes OpenID Connect 令牌身份驗證器插件使用 ID 令牌。此時的結果可以是驗證或拒絕用戶。如果用戶成功通過身份驗證，API 服務器將使用 ID 令牌信息來應用 RBAC 規(guī)則。
- 來自 API 服務器的響應被發(fā)送回kubectl客戶端。
- 客戶端將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) 所示，并非所有身份提供者都支持刷新令牌請求。這意味著根據(jù)身份提供者的不同，用戶將不得不不時重復上一節(jié)中描述的身份驗證過程。
此外，并非所有的 Dex 連接器都是穩(wěn)定的。Google、Bitbucket Cloud 和 OAuth 2.0 的連接器狀態(tài)仍為 alpha。
要記住的另一點是，Dex 僅用作身份驗證解決方案。環(huán)境變量、kube-contexts 和成本的管理必須手動完成或通過使用其他工具完成。
結論
在本文中，您了解到 Dex 是一種可行的解決方案，可以通過 Kubernetes 獲得更好的登錄體驗。
作為 OIDC 提供商，Dex 允許您的組織利用正在使用的身份提供商連接到 Kubernetes。
這是一個巨大的優(yōu)勢，因為無需添加額外的基礎設施，您的組織就可以為 Kubernetes 實施集中式身份管理，從而節(jié)省時間并有助于改進安全策略。
原文： ?https://loft.sh/blog/dex-for-kubernetes-how-does-it-work/
當前名稱：詳解使用Dex實現(xiàn)Kubernetes身份驗證
當前鏈接：http://www.5511xx.com/article/dhpiioh.html
