learning/k8s-advanced/sec/authenticate/install.md
本文描述了如何为已有 Kubernetes 集群安装认证模块，并可以通过 GitLab、GitHub、LDAP 中的已有账号登录 Kubernetes 集群。
<Course courseId="484058" />Kubernetes 支持 多种认证方式 ，关于安装 Kubernetes 认证模块的资料比较少，基本上只有 Kubernetes 相关的商业化产品才提供这方面的能力，原因在于：
针对这个情况，Kuboard 提供了一个免费的解决方案，通过提供 Kubernetes 认证模块安装向导，帮助用户便捷的安装 Kubernetes 认证模块，轻松使用企业中已有账号系统（GitLab ce、GitLab ee、GitHub enterprise、LDAP 等）的账号登录 Kubernetes。
安装向导本身的指示性很强，直接按照向导的指示，就可以完成 Kubernetes 认证模块的安装。本文后面的章节将对向导中的每个步骤做更详细的阐述性说明，帮助大家除了理解怎么做之外，还能理解为什么这么做。
::: tip 多种认证方式并存
:::
当 Kuboard 版本不低于 v1.0.6-beta.7 时，可以通过 http://yournodeip:32567/authenticate-install 链接进入 Kuboard 认证模块安装向导。如下图所示：
Kuboard v2.0.x 中，此链接仍然有效，界面风格与 v1.0.x 有差异，但是认证模块安装向导的功能相同。
Kuboard 目前支持的认证模式有：
当使用 OpenID Connect 模式进行用户认证时，Kuboard 可以通过 Dex 连接多种类型的 Identity Provider，也可以直连 Identity Provider。
Dex 支持的 Identity Provider 有多种类型，请参考 Dex 文档，目前 Kuboard OpenID Connect 认证安装向导里支持的 Dex - Identity Provider 有：
::: tip 为什么不直连 GitLab
下图描述了使用 Dex 连接 Identity Provider 时的认证过程，使用 Dex 连接 Identity Provider 的情况下，Kubernetes Authenticate 安装向导将引导您：
如果选择 GitLab 作为 Identity Provider：
openid、read_user 这两个 scope，如下图所示，Client ID、Client Secret 两个字段回填到 Kubernetes Authentication 安装向导。Client ID、Client Secret 两个字段回填到 Kubernetes Authentication 安装向导。直连 Identity Provider 时，已经验证的 Identity Provider 有：
下图描述了直连 Identity Provider 时，用户认证的过程。此时，Kubernetes Authenticate 安装向导将引导您：
Kubernetes Authentication 安装向导中，请按照如下步骤完成 Dex 的安装：
填写参数，如下图所示：
此步骤中的参数都无需修改，因为在前一个步骤 准备 环节，已经填写了，其他的参数由 Kubernetes Authentication 安装向导为您生成。
如果您希望多个 Kubernetes 集群都使用这一个 Dex 实例，请在下图表单中新增一个 Dex Client 的信息。
保存上图表单后，点击 安装 按钮
Kubernetes Authentication 安装向导将在此 Kubernetes 集群安装 Dex，如需要了解具体安装的内容，可在安装过程中预览 Dex 的安装文件，也可以参考 Dex 的文档，已了解更多关于 Dex 的知识。
完成 Dex 安装后，Kubernetes Authenticate 安装向导将引导您确认一些信息，点击 已确认 按钮，可进入下一个步骤，设定 Kuboard OIDC
设定 Kuboard OIDC 参数时，可以选择两种认证方式：
设定 Kuboard OIDC 参数时，oidc 相关的主要参数有 issuer-url、client-id、client-secret、username-claim、username-prefix、groups-claim、groups-prefix。这些参数与 Kubernetes OpenID Connect 的配置参数存在一一映射的关系，关于这些参数的详细说明，请参考 Kubernetes OIDC 参数说明
当您使用 Dex 连接 Github、GitLab 时，Kubernetes Authenticate 安装向导为您默认生成此表单的参数，无需修改，直接保存即可。
保存 Kuboard OIDC 参数的表单以后，点击 应用 Kuboard OIDC 配置 的按钮，Kubernetes Authenticate 安装向导将对 Kubernetes 集群完成如下变更：
创建一个 ConfigMap kube-system/kuboard-authenticate-config ，将 Kuboard OIDC 参数保存到此表单中。
更新 Deployment kube-system/kuboard 的环境变量 OIDC_USSER，如下所示：
containers:
- env:
- name: OIDC_ISSUER
value: 'https:\/\/dex.demo.kuboard.cn:32001'
创建 ClusterRole kuboard-authenticate 和 ClusterRoleBinding kuboard-authenticate-rolebinding，授权匿名用户可以查看 ConfigMap kube-system/kuboard-authenticate-config 的内容（Kuboard 登录界面上在用户未登录时，就需要使用这些参数）。
将 Kuboard OIDC 参数应用到集群之后，Kubernetes Authenticate 安装向导将引导您检查这些参数的应用结果，您可能需要多点击几次刷新按钮才能看到最终的成功结果，因为 Kuboard Deployment 的环境变量修改之后，会重新启动一个新的 Kuboard Pod，新 Pod 启动之后，才能生效。
在验证 Kuboard 可以访问 Identity Provider 之后，点击 下一步 进入 设置 Apiserver 的环节。
设置 Apiserver 时，Kubernetes Authenticate 安装向导将引导您完成如下步骤：
在完成 Apiserver 参数的配置之后，点击 下一步 进入 授权 环节。
到此为止，Kuboard 的登录界面已经可以引导您使用您配置的 OpenID Connect Identity Provider 进行用户认证，且，Kubernetes apiserver 也能识别登录后的用户身份。但是，您仍然不能进入 Kuboard 界面，或对 Kubernetes 执行任何操作，因为，您还没有为用户/用户组授权。
您可以在 Kuboard 界面中完成对用户/用户组的授权，而无需编写 ClusterRole、Role、ClusterRoleBinding、RoleBinding 等对象的 yaml 文件。
请记住，此时有如下限制：
参考 使用Kuboard管理ServiceAccount及RBAC
::: tip kubectl
由于 Kubectl 是一个命令行工具，没有图形化 Web 界面，不能发起和完成 OIDC 认证流程（不能接收 OAuth 2 授权码等认证流程中的 web url 回调），完成此配置之后，如果要使用 Github、GitLab 等 Identity Provider 中的账号登录 Kubectl，您需要先登录 Kuboard，然后在 Kuboard 的当前用户界面上获得 kubectl 的配置参数，方可使用 kubectl 。
:::
至此，您已经可以使用 GitHub、GitLab等 Identity Provider 中的账号登录 Kuboard / Kubectl。下一步，您可以：