要部署清单，我们将使用 Jsonnet 生成将部署到每个集群中的清单。生成的这些清单通过更改集群相关选项的单个 config.jsonnet 文件进行配置。完成后，此文件应存储在 kube-oidc-proxy/demo 目录中。

下面的示例显示的是 config.jsonnet 文件完成时的样子。接下来的几个步骤将指导您创建文件。

local main = import './manifests/main.jsonnet';

function(cloud='amazon_cluster_1') main {
  cloud: cloud,
  clouds+: {
    amazon_cluster_1: {
      master: true,
      domain_part: '.cluster-1',
      config: import './manifests/amazon_cluster_1-config.json',
    },
    amazon_cluster_2: {
      master: false,
      domain_part: '.cluster-2',
      config: import './manifests/amazon_cluster_2-config.json',
    },
    amazon_cluster_3: {
      master: false,
      domain_part: '.cluster-3',
      config: import './manifests/amazon_cluster_3-config.json',
    },
    google: null,
    amazon: null,
    digitalocean: null,
  },
  base_domain: '.eks.aws.joshvanl.com',
  cert_manager+: {
    letsencrypt_contact_email:: 'xxxxxx@gmail.com',
    solvers+: [
      {
        http01: {
          ingress: {},
        },
      },
    ],
  },
  dex+: if $.master then {
    connectors: [
      $.dex.Connector('github', 'GitHub', 'github', {
        clientID: 'xxx',
        clientSecret: 'xxx',
        homePage: 'eks.aws.joshvanl.com',
      }),
    ],
  } else {
  },
}

首先，我们将引用我们创建的每个集群以及生成的密码，因为它们将用于构建身份验证基础设施。我们还需要表示单个主集群，以容纳 Dex 和登陆 Web 服务器部署，以服务基础设施中的所有其他集群。

function(cloud='amazon_cluster_1') main {
  cloud: cloud,
  clouds+: {
    amazon_cluster_1: {
      master: true,
      domain_part: '.cluster-1',
      config: import './manifests/amazon_cluster_1-config.json',
    },
    amazon_cluster_2: {
      master: false,
      domain_part: '.cluster-2',
      config: import './manifests/amazon_cluster_2-config.json',
    },
    amazon_cluster_3: {
      master: false,
      domain_part: '.cluster-3',
      config: import './manifests/amazon_cluster_3-config.json',
    },
    google: null,
    amazon: null,
    digitalocean: null,
  },

接下来，表示您拥有的基本域的域名，它将用于连接各个集群。基本域还将用于 URL，稍后，您可将它用于连接登陆页面。

将“.eks.aws.joshvanl.com”替换为您自己的基本域。

base_domain: '.eks.aws.joshvanl.com',

配置 cert-manager，以设置账户电子邮件地址以及我们在请求证书时希望解决的问题。我们将在这里使用 HTTP01 解决问题。

将“xxxxxx@gmail.com”替换为您自己的联系电子邮件地址。

cert_manager+: {
    letsencrypt_contact_email:: 'xxxxxx@gmail.com',
    solvers+: [
      {
        http01: {
          ingress: {},
        },
      },
    ],
  },

最后，设置您希望用于 Dex 的连接器。

dex+: if $.master then {
    connectors: [
      $.dex.Connector('github', 'GitHub', 'github', {
        clientID: 'xxx',
        clientSecret: 'xxx',
        homePage: 'eks.aws.joshvanl.com',
      }),
    ],
  } else {
  },

这些连接器用于完成 OAuth 流，从而对新用户身份进行验证。完成 OAuth 流时，Dex 将签署包含该颁发机构接收和验证的身份的 OIDC 令牌。在本例中，我们将使用 GitHub 应用程序。OAuth 流将根据用户的 GitHub 配置文件通过其 GitHub 账户和其身份进行解决。您可以在构建 OAuth 应用程序中了解有关如何创建 GitHub OAuth 应用程序的更多信息。

使用创建的集群和编写的配置，我们可以开始安装组件。

将清单部署到主集群中：

$ CLOUD=amazon_cluster_1 make manifests_apply

此操作应该将所有组件安装到适当配置的集群中。为了解决 HTTP01 问题并使集群可以通过您选择的基本域从 Internet 进行路由，请等待 ExternalIP 公开 LoadBalancer 类型的服务。

$ export KUBECONFIG=.kubeconfig-amazon_cluster_1
$ kubectl get services --namespace auth
$ kc get svc -n auth
NAME                        TYPE           CLUSTER-IP       EXTERNAL-IP                                                               PORT(S)                      AGE
contour                     LoadBalancer   172.20.221.86    a21a97cf9d40e11e9b58302e1256987f-1040136959.eu-west-1.elb.amazonaws.com   443:31844/TCP,80:32636/TCP   105s
dex                         ClusterIP      172.20.147.161   <none>                                                                    5556/TCP                     104s
gangway                     ClusterIP      172.20.69.133    <none>                                                                    8080/TCP                     80s
kube-oidc-proxy             ClusterIP      172.20.60.178    <none>                                                                    443/TCP                      79s
landingpage                 ClusterIP      172.20.90.110    <none>                                                                    80/TCP                       79s

生成这些项目后，创建三个指向登陆页面 URL 的 CNAME 记录，Dex 服务器和一个指向该集群内的组件的通配符记录。您可以发现为此集群生成的入口记录如下所示：

$ kubectl get ingressroutes --namespace auth
NAME              FQDN                                             TLS SECRET   FIRST ROUTE   STATUS   STATUS DESCRIPTION
dex               dex.eks.aws.joshvanl.com                                      /             valid    valid IngressRoute
gangway           gangway.cluster-1.eks.aws.joshvanl.com                        /             valid    valid IngressRoute
kube-oidc-proxy   kube-oidc-proxy.cluster-1.eks.aws.joshvanl.com                /             valid    valid IngressRoute

$ kubectl get ingress --namespace auth
landingpage                 gangway.cluster-1.eks.aws.joshvanl.com,kube-oidc-proxy.cluster-1.eks.aws.joshvanl.com,dex.eks.aws.joshvanl.com + 1 more...            80, 443   14s

这需要三个如下所示的 CNAME 记录：

.cluster-1.eks.aws  CNAME 1h a21a97cf9d40e11e9b58302e1256987f-1040136959.eu-west-1.elb.amazonaws.com.
dex.eks.aws          CNAME 1h a21a97cf9d40e11e9b58302e1256987f-1040136959.eu-west-1.elb.amazonaws.com.
eks.aws              CNAME 1h a21a97cf9d40e11e9b58302e1256987f-1040136959.eu-west-1.elb.amazonaws.com.

当 DNS 记录传播到 Internet 之后，证书 HTTP01 挑战应成功，且证书应签发。您可以通过检查证书资源状态和 cert-manager 控制器中的日志输出来查看签发证书的状态：

$ kubectl get certificates --namespace auth
NAME              READY   SECRET                AGE
dex               True    dex-tls               13s
gangway           True    gangway-tls           13s
kube-oidc-proxy   True    kube-oidc-proxy-tls   12s
landingpage       True    landingpage-tls       12s

$ kubectl logs --namespace cert-manager cert-manager-xxx

注意：如果您收到证书错误，请回收 Kube-OIDC-Proxy、Dex 和 Gangway pod。

当证书签发后，您应该能够访问 Kube-OIDC-Proxy Demo 登陆页面：

由于我们只部署了一个集群，只有第一个集群才能访问实时 Gangway。通过点击 GANGWAY AMAZON_CLUSTER_1 的按钮，我们可以通过对 GitHub 进行身份验证来请求第一个集群的 OIDC 令牌。

当您下载 kubeconfig 后，您应该能够使用 Kube-OIDC-Proxy 通过我们的 OIDC 令牌连接到此集群。

$ kubectl --kubeconfig ~/Downloads/kubeconfig get nodes
服务器错误（禁止）：节点被禁止：用户“xxxxxx@gmail.com”无法在集群范围内在 API 组 "" 中列出资源“节点”

由于我们尚未应用此用户的任何 RBAC 权限，此命令失败。然而，它确实表明我们正在以 GitHub 的身份连接。现在，我们可以分配此用户 cluster-admin 权限，但您很可能希望为您自己的集群的租户创建更严格、更精细化的权限。

将 xxxxxx@gmail.com 替换为有效的 GitHub ID。

$ kubectl create clusterrolebinding xxxxxx@gmail.com --clusterrole cluster-admin --user xxxxxx@gmail.com
clusterrolebinding.rbac.authorization.k8s.io/xxxxxx@gmail.com created
$ kubectl --kubeconfig ~/Downloads/kubeconfig get nodes
NAME                                       STATUS   ROLES    AGE     VERSION
ip-10-0-2-136.eu-west-1.compute.internal   Ready    <none>   32m   v1.14.6-eks-5047ed
ip-10-0-3-178.eu-west-1.compute.internal   Ready    <none>   32m   v1.14.6-eks-5047ed
ip-10-0-3-50.eu-west-1.compute.internal    Ready    <none>   32m   v1.14.6-eks-5047ed

现在，第一个集群已配置完成，我们准备为接下来的两个集群重复此过程。请记住创建指向新集群终端节点的新 CNAME 记录，以便它们可以通过 Internet 进行路由，并且能够解决 HTTP01 问题。

$ CLOUD=amazon_cluster_2 make manifests_apply
$ CLOUD=amazon_cluster_3 make manifests_apply

由于位于主集群中的项目将在所有集群中共享，那些非主集群都将不会部署 Dex 或登陆页面。

完成后，所有三个集群都将准备好请求令牌，并且可以使用 OIDC 进行访问。

总结

使用 Kube-OIDC-Proxy 可使具有多集群、多租户 Kubernetes 基础设施的组织促进基于第三方身份提供商的一致性 OIDC 身份验证。在此博文中，我演示了如何将其他开源项目与 Kube-OIDC-Proxy 结合使用为集群的最终用户创建简化的登录体验。

该项目的未来开发将涉及创建更多选项来处理带有和不带有令牌的代理请求，以及实施审计。您可以在此了解该项目并关注 GitHub 的进度。

本博文中的内容和意见属于第三方作者，AWS 不对本博文的内容或准确性负责。

本文转载自AWS技术博客。

原文链接：https://amazonaws-china.com/cn/blogs/china/consistent-oidc-authentication-across-multiple-eks-clusters-using-kube-oidc-proxy/

创作场景

使用 Kube-OIDC-Proxy 跨多个 EKS 集群进行一致的 OIDC 身份验证（二）