Amazon Elastic Kubernetes Service (Amazon EKS) 对 IAM 进行用户身份验证,然后再授予用户至 EKS 集群的访问权。至每个集群的访问权由 aws-auth ConfigMap
进行控制,该文件将 IAM 用户/角色映射到 Kubernetes RBAC 组。在来自 Jetstack 的 Josh Van Leeuwen 发表的客座博文中,我们将讨论如何使用多个开源项目跨多个集群对 GitHub 等 OIDC 提供商进行用户身份验证。
Kube-OIDC-Proxy 是 Jetstack 开发的开源反向代理,可以为各个后端启用 OIDC 身份验证。对于 EKS,可以使用第三方提供商提供的相同用户身份对多个 EKS 集群进行 OIDC 身份验证。此博文将探讨 Kube-OIDC-Proxy 的工作原理,如何将其部署到多个 EKS 集群中以及如何利用其它开源工具为最终用户提供无缝身份验证经验。
它的工作原理是什么?
OIDC 或 OpenID Connect 是现有 OAuth 2.0 协议的扩展协议。OIDC 流从用户从一个身份提供商处请求 JSON Web 令牌开始,其中包含范围适当的用户相关属性列表。内容包括如下属性,如电子邮件地址或名称、包含有关令牌本身的额外信息的标头,例如签名算法,以及身份提供商签署之令牌的签名。此签名将被资源服务器用于根据身份提供商提供的证书颁发机构验证令牌内容。
Kube-OIDC-Proxy 是基于 Kubernetes 内部的反向代理,它使用 OIDC 对请求进行身份验证。然后,这些经过身份验证的请求被转发至一些后端,如 Kubernetes API Server,并根据传入的 OIDC 令牌所验证的身份附加模拟标头。这与 OIDC 身份验证不可配置的 Kubernetes API 服务器非常匹配,因为请求可以由 Kube-OIDC-Proxy 使用 OIDC 令牌的身份通过 RBAC 进行模拟。
部署
要创建功能完备的多集群 OIDC 身份验证基础设施,我们可以使用其他开源项目来集成外部 OIDC 提供商,并为最终用户提供友好的体验。也就是说,我们将使用以下项目:
Cert-Manager:一种证书管理工具,用于请求和自动更新 Kubernetes 中的 TLS 证书,包括 Let’s Encrypt 的证书。
Dex:一个 OIDC 提供商,为外部 OAuth 提供商提供连接器以获取身份;在本例中,将使用 GitHub 应用程序。Dex 的单个实例将被部署到主集群中,为所有集群中的所有其他组件提供服务,包括签署 OIDC 令牌。
Gangway:促进 OAuth 流获取必要的用户身份的一个网站,从而从提供商处形成 OIDC 令牌并根据这些令牌为最终用户自动生成 Kubeconfigs。
Contour:Envoy 代理支持的一个入口控制器,可使用单个公开负载均衡器将流量路由至不同组件中。TLS 透传启用,表示 TLS 连接在每个应用程序中终止,而不是在边缘,从而防止未加密的流量在集群中传递。
NGINX:用作 HTTP Web 服务器,以提供登陆页面,帮助最终用户跨集群轻松导航至不同的 Gangway。单个实例将部署到主集群中,从而为所有集群提供服务。
Kube-OIDC-Proxy:反向代理,用户将通过其进行身份验证以便访问每个集群中的 API 服务器。
部署 Kube-OIDC-Proxy
首先,从 GitHub 中克隆 kube-oidc 存储库:
创建一个或多个 EKS 集群,以供 Kube-OIDC-Proxy 用于进行身份验证。使用 Kube-OIDC-Proxy 存储库,将 EKS Terraform 模块复制到所需的任何数量和名称。
注意:此步骤需要 Hashicorp 的 Terraform。您可以从 Terraform 下载页面获取 Terraform CLI。从 zip 文件中提取二进制文件,然后将二进制文件复制到您的路径中。可以通过访问安装 Terraform 获取进一步说明。
注意:默认情况下,EKS 集群在 eu-west-1 区域中创建。如果您想要在另一个区域中创建集群,请使用您的首选区域名称更新 kube-oidc-proxy/demo/infrastructure/amazon/providers.tf
文件,然后完成此步骤。
应用 terraform 配置以建立这些集群:
完成后,应创建好三个集群。同时也应该有三个 Kubeconfig 文件根据常用方法通过 AWS 对这些集群进行身份验证。
注意:如果前述步骤创建工作线程节点或 kubeconfig 文件失败,请重新运行 terraform_apply
。
本文转载自 AWS 技术博客。
评论