尽管Kubernetes是当今使用最广泛的开源容器编排平台，但它没有创建和管理用户的手段，至少没有本地方式。然而，这并不是一个缺点，因为它可以对接多种认证服务。也正因此，Dex已成为Kubernetes可用的最佳身份验证解决方案之一。
在本文中，您将了解有关 Dex for Kubernetes 的更多信息。我们将探讨它可以解决的一些问题，通过使用第三方身份提供者进行设置的高级概述，并考虑 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 通过允许管理员使用组织的身份服务提供者来管理用户和组来扩展 Kubernetes 的功能。然而，这并不是 Dex 解决的唯一问题。让我们来看看它提供的其他一些好处。Dex 以多种方式提高了 Kubernetes 集群的安全性：- 它提供了一种通过身份提供者将用户登录到集群的安全方式。
- 它消除了与为多个用户使用相同的 kubeconfig 文件相关的安全风险。
- 由于使用 RBAC 规则（零信任 RBAC 访问）进行有效的用户和组管理，它有助于执行身份验证和授权策略。
每个组织都有独特的要求，而 Dex 足够灵活，几乎可以使用任何身份提供者。Okta、GitHub、GitLab、Microsoft、Linkedin 以及使用 OpenID Connect、OAuth 2.0、LDAP 和 SAML 2.0 协议等的服务可用的连接器就是证明。 更多Dex的信息请操作github地址。(https://github.com/dexidp/dex)实施 Dex 可能不是小型团队的最佳解决方案。但是，对于拥有数十名用户分布在不同团队中的组织来说，Dex 是一个非常强大的工具。不必手动创建、管理和分发 kubeconfig 文件在节省时间和安全性方面都是一个巨大的优势。此外，Dex 通过实现更精细的访问控制来补充 Kubernetes。正如您将在下一节中看到的，Dex 控制 ID 令牌的发行，允许您指定其持续时间，这对于涉及临时用户访问的情况非常方便。此外，如有必要，您可以撤销所有 ID 令牌。您甚至可以撤销特定用户或组的访问权限。总而言之，Dex 可以让你为 Kubernetes 添加一个高效易用的集中式认证系统。使用 Dex 在 Kubernetes 上
设置身份验证
正如我们已经建立的那样，Dex 充当了一个门户，它使用连接器将 Kubernetes 与多个身份提供者链接起来。
- 最终用户发起登录 Dex 的请求。这通常通过用户启动单点登录的 Web 应用程序或门户来完成。
- Dex 将此请求转发给第三方身份提供商（例如，Active Directory、Google、GitHub 或 Okta）。为此，Dex 使用“connectors”，它具有一系列用于查询其他用户管理系统的协议。
- 多亏了这些“connectors”，Dex 可以从身份提供者那里访问相关的用户信息，例如姓名、电子邮件、唯一标识符、组、访问令牌等。在 Okta 的情况下，这些数据以 ID 令牌的形式出现。根据Dex 文档，“ID 令牌是 JSON Web 令牌 (JWT)……作为证明最终用户身份的 OAuth2 响应的一部分返回。”
- 一旦 Dex 从第三方上游身份提供者那里获得了用户信息，它就会承担身份提供者的角色，并颁发一个签名的 ID 令牌发送给
kubectl客户端，客户端将 JWT 转发给 API 服务器。 - API 服务器使用 Kubernetes OpenID Connect 令牌身份验证器插件使用 ID 令牌。此时的结果可以是验证或拒绝用户。如果用户成功通过身份验证，API 服务器将使用 ID 令牌信息来应用 RBAC 规则。
- 来自 API 服务器的响应被发送回
kubectl客户端。
有关通过 LDAP 进行身份验证的信息，请阅读此处(https://dexidp.io/docs/connectors/ldap/) 的文档。有关如何通过 OpenID Connect 提供程序（例如 Okta）进行身份验证的其他信息，请参阅此处(https://dexidp.io/docs/connectors/oidc/) 的文档。尽管 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/
