diff --git a/.vuepress/config-sidebar.js b/.vuepress/config-sidebar.js index 302c27e..1e67ed6 100644 --- a/.vuepress/config-sidebar.js +++ b/.vuepress/config-sidebar.js @@ -404,15 +404,28 @@ module.exports = { title: '安全', collapsable: true, children: [ - 'k8s-advanced/sec/sa-admin', - 'k8s-advanced/sec/kuboard', - 'k8s-advanced/sec/rbac/api', - 'k8s-advanced/sec/rbac/default', - 'k8s-advanced/sec/rbac/escalation', - 'k8s-advanced/sec/rbac/cmd', - 'k8s-advanced/sec/rbac/sa', - 'k8s-advanced/sec/rbac/permissive', - 'k8s-advanced/sec/rbac/example', + { + title: '用户认证', + collapsable: true, + children: [ + 'k8s-advanced/sec/authenticate/', + 'k8s-advanced/sec/sa-admin', + 'k8s-advanced/sec/authenticate/install', + ] + }, { + title: '用户授权', + collapsable: true, + children: [ + 'k8s-advanced/sec/kuboard', + 'k8s-advanced/sec/rbac/api', + 'k8s-advanced/sec/rbac/default', + 'k8s-advanced/sec/rbac/escalation', + 'k8s-advanced/sec/rbac/cmd', + 'k8s-advanced/sec/rbac/sa', + 'k8s-advanced/sec/rbac/permissive', + 'k8s-advanced/sec/rbac/example', + ] + }, ] }, { diff --git a/install/faq/apiserver-params.md b/install/faq/apiserver-params.md new file mode 100644 index 0000000..b3c18ab --- /dev/null +++ b/install/faq/apiserver-params.md @@ -0,0 +1,142 @@ +--- +description: 修改 Kubernetes apiserver 启动参数 +--- + +# 修改 Kubernetes apiserver 启动参数 + +本文描述了修改 Kubernetes apiserver 启动参数的步骤。 + +如果您使用 kubeadm 安装 Kubernetes 集群，Kubernetes apiserver 通过 static pod 启动，其 yaml 文件的位置在 `/etc/kubernetes/manifest/kube-apiserver.yaml` 这个路径下，如下所示：（其中第 14 行到第 39 行，都是 kube-apiserver 的启动参数） + +``` yaml {14-39} +apiVersion: v1 +kind: Pod +metadata: + creationTimestamp: null + labels: + component: kube-apiserver + tier: control-plane + name: kube-apiserver + namespace: kube-system +spec: + containers: + - command: + - kube-apiserver + - --advertise-address=172.17.184.171 + - --allow-privileged=true + - --authorization-mode=Node,RBAC + - --client-ca-file=/etc/kubernetes/pki/ca.crt + - --enable-admission-plugins=NodeRestriction + - --enable-bootstrap-token-auth=true + - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt + - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt + - --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key + - --etcd-servers=https://127.0.0.1:2379 + - --insecure-port=0 + - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt + - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key + - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname + - --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt + - --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key + - --requestheader-allowed-names=front-proxy-client + - --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt + - --requestheader-extra-headers-prefix=X-Remote-Extra- + - --requestheader-group-headers=X-Remote-Group + - --requestheader-username-headers=X-Remote-User + - --secure-port=6443 + - --service-account-key-file=/etc/kubernetes/pki/sa.pub + - --service-cluster-ip-range=10.96.0.0/16 + - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt + - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key + image: registry.cn-hangzhou.aliyuncs.com/google_containers/kube-apiserver:v1.17.1 + imagePullPolicy: IfNotPresent + livenessProbe: + failureThreshold: 8 + httpGet: + host: 172.17.184.171 + path: /healthz + port: 6443 + scheme: HTTPS + initialDelaySeconds: 15 + timeoutSeconds: 15 + name: kube-apiserver +... +``` + +假设您要向 Kubernetes apiserver 追加如下 oidc 参数时，将这些参数追加到该 yaml 文件的 `command` 字段中即可， +``` yaml + - --oidc-issuer-url=https://dex.demo.kuboard.cn:32001 + - --oidc-client-id=kuboard-dex-client + - --oidc-username-claim=preferred_username + - --oidc-username-prefix=- + - --oidc-groups-claim=groups + - --oidc-groups-prefix= +``` + +修改后的文件如下所示： +``` yaml {40-45} +apiVersion: v1 +kind: Pod +metadata: + creationTimestamp: null + labels: + component: kube-apiserver + tier: control-plane + name: kube-apiserver + namespace: kube-system +spec: + containers: + - command: + - kube-apiserver + - --advertise-address=172.17.184.171 + - --allow-privileged=true + - --authorization-mode=Node,RBAC + - --client-ca-file=/etc/kubernetes/pki/ca.crt + - --enable-admission-plugins=NodeRestriction + - --enable-bootstrap-token-auth=true + - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt + - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt + - --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key + - --etcd-servers=https://127.0.0.1:2379 + - --insecure-port=0 + - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt + - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key + - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname + - --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt + - --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key + - --requestheader-allowed-names=front-proxy-client + - --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt + - --requestheader-extra-headers-prefix=X-Remote-Extra- + - --requestheader-group-headers=X-Remote-Group + - --requestheader-username-headers=X-Remote-User + - --secure-port=6443 + - --service-account-key-file=/etc/kubernetes/pki/sa.pub + - --service-cluster-ip-range=10.96.0.0/16 + - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt + - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key + - --oidc-issuer-url=https://dex.demo.kuboard.cn:32001 + - --oidc-client-id=kuboard-dex-client + - --oidc-username-claim=preferred_username + - --oidc-username-prefix=- + - --oidc-groups-claim=groups + - --oidc-groups-prefix= + image: registry.cn-hangzhou.aliyuncs.com/google_containers/kube-apiserver:v1.17.1 + imagePullPolicy: IfNotPresent + livenessProbe: + failureThreshold: 8 + httpGet: + host: 172.17.184.171 + path: /healthz + port: 6443 + scheme: HTTPS + initialDelaySeconds: 15 + timeoutSeconds: 15 + name: kube-apiserver +... +``` + +::: tip 生效 +Static Pod 的配置文件被修改后，立即生效。 +* Kubelet 会监听该文件的变化，当您修改了 `/etc/kubenetes/manifest/kube-apiserver.yaml` 文件之后，kubelet 将自动终止原有的 kube-apiserver-{nodename} 的 Pod，并自动创建一个使用了新配置参数的 Pod 作为替代。 +* 如果您有多个 Kubernetes Master 节点，您需要在每一个 Master 节点上都修改该文件，并使各节点上的参数保持一致。 +::: diff --git a/learning/k8s-advanced/sec/authenticate/install.assets/image-20200201152914338.png b/learning/k8s-advanced/sec/authenticate/install.assets/image-20200201152914338.png new file mode 100644 index 0000000..943752d Binary files /dev/null and b/learning/k8s-advanced/sec/authenticate/install.assets/image-20200201152914338.png differ diff --git a/learning/k8s-advanced/sec/authenticate/install.assets/image-20200201160933419.png b/learning/k8s-advanced/sec/authenticate/install.assets/image-20200201160933419.png new file mode 100644 index 0000000..8acf64e Binary files /dev/null and b/learning/k8s-advanced/sec/authenticate/install.assets/image-20200201160933419.png differ diff --git a/learning/k8s-advanced/sec/authenticate/install.assets/image-20200201174418018.png b/learning/k8s-advanced/sec/authenticate/install.assets/image-20200201174418018.png new file mode 100644 index 0000000..0088825 Binary files /dev/null and b/learning/k8s-advanced/sec/authenticate/install.assets/image-20200201174418018.png differ diff --git a/learning/k8s-advanced/sec/authenticate/install.assets/image-20200201180554307.png b/learning/k8s-advanced/sec/authenticate/install.assets/image-20200201180554307.png new file mode 100644 index 0000000..8c66722 Binary files /dev/null and b/learning/k8s-advanced/sec/authenticate/install.assets/image-20200201180554307.png differ diff --git a/learning/k8s-advanced/sec/authenticate/install.assets/image-20200201181823835.png b/learning/k8s-advanced/sec/authenticate/install.assets/image-20200201181823835.png new file mode 100644 index 0000000..4d0bb0a Binary files /dev/null and b/learning/k8s-advanced/sec/authenticate/install.assets/image-20200201181823835.png differ diff --git a/learning/k8s-advanced/sec/authenticate/install.md b/learning/k8s-advanced/sec/authenticate/install.md new file mode 100644 index 0000000..55adc7f --- /dev/null +++ b/learning/k8s-advanced/sec/authenticate/install.md @@ -0,0 +1,229 @@ +--- +vssueId: 180 +layout: LearningLayout +description: Kubernetes教程_除了ServiceAccount以外，Kubernetes不提供任何形式的用户认证方式，如果需要通过用户名密码登录Kubernete/Kuboard，本文描述使用Kubernetes 认真模块安装向导为已有的 Kubernetes 集群增加用户认证功能，并可以使用 GitHub、GitLab 账号登录 Kubernetes。 +meta: + - name: keywords + content: Kubernetes 教程,Kubernetes 授权,Kubernetes authentication,Kubernetes用户名密码 + +--- + +# Kubernetes Authenticate 安装向导 + + + +本文描述了如何为已有 Kubernetes 集群安装认证模块，并可以通过 GitLab、GitHub、LDAP 中的已有账号登录 Kubernetes 集群。 + +## 前提条件 + +* 您已经安装了 Kubernetes 集群 + * 版本不低于 Kubernetes v1.13.0 + * 可参考 [安装Kubernetes单Master节点](/install/install-k8s.html) +* 您已经安装了 Kuboard + * 版本不低于 Kuboard v1.0.6-beta.7 + * 可参考 [安装Kuboard](/install/install-dashboard.html) + +## Kubernetes认证模块安装向导 + +Kubernetes 支持 [多种认证方式](./#认证策略) ，关于安装 Kubernetes 认证模块的资料比较少，基本上只有 Kubernetes 相关的商业化产品才提供这方面的能力，原因在于： + +* 各企业对 Kubernetes 用户信息的管理方式和过程各不相同； +* 为了保持通用性，Kubernetes 并不内置用户/用户组的管理和分发流程，需要做许多集成开发和自定义配置的工作； +* Kubernetes dashboard 暂未支持第三方认证方式，kubectl 作为命令行工具，不能直接与 OpenID Connect 或 Webhook 等认证流程集成； +* Kubernetes 与第三方认证集成时，涉及到的组件、配置环节多且复杂，单纯依靠文档描述，仍然不能取得非常好的效果。 + +针对这个情况，Kuboard 提供了一个免费的解决方案，通过提供 Kubernetes 认证模块安装向导，帮助用户便捷的安装 Kubernetes 认证模块，轻松使用企业中已有账号系统（GitLab ce、GitLab ee、GitHub enterprise、LDAP 等）的账号登录 Kubernetes。 + +安装向导本身的指示性很强，直接按照向导的指示，就可以完成 Kubernetes 认证模块的安装。本文后面的章节将对向导中的每个步骤做更详细的阐述性说明，帮助大家除了理解怎么做之外，还能理解为什么这么做。 + +::: tip 多种认证方式并存 + +* Kubernetes 内建 ServiceAccount 的认证方式， +* 您应该为集群配置额外的认证方式用于认证普通用户， +* Kubernetes 在启动和运行时，不依赖于第三方认证模块： + * 当第三方认证模块不可用时，Kubernetes仍然可以正常工作，您仍然可以使用 ServiceAccount登录 Kuboard / Kubectl + * 当第三方认证模块可用时，您可以使用第三方账号系统的账号登录 Kuboard / Kubectl + +::: + +### 进入Kubernetes认证模块安装向导 + +当 Kuboard 版本不低于 v1.0.6-beta.7 时，可以通过 http://yournodeip:32567/authenticate-install 链接进入 Kuboard 认证模块安装向导。如下图所示： + +![Kubernetes安装认证模块](./install.assets/image-20200201160933419.png) + + + + + +## 安装认证模块 + +### 准备安装 + +Kuboard 目前支持的认证模式有： +* OpenID Connect +* Web hook 计划中 + +当使用 OpenID Connect 模式进行用户认证时，Kuboard 可以通过 [Dex](https://github.com/dexidp/dex) 连接多种类型的 Identity Provider，也可以直连 Identity Provider。 + +#### Dex - Identity Provider + +Dex 支持的 Identity Provider 有多种类型，请参考 [Dex](https://github.com/dexidp/dex) 文档，目前 Kuboard OpenID Connect 认证安装向导里支持的 Dex - Identity Provider 有： + +* GitHub + * Github.com + * Github Enterprise +* GitLab + * Gitlab.com + * GitLab CE + * GitLab + +::: tip 为什么不直连 GitLab +* 尽管 GitLab 也实现了 OpenID Connect 协议，但是通过 GitLab OpenID Connect 直接获取的 jwt Token 中只包括 sub 和 sub_legacy 字段，没有 groups / username 等信息，Kubernetes OpenID Connect 不能直连 GitLab OpenID Connect。此时，Dex 作为 Kubernetes 与 GitLab 的桥接，Dex 在获得 GitLab Token 之后，额外再向 GitLab 接口获取到 username / groups / email 等信息之后，重新生成 jwt Token，用于 Kubernetes 的认证。请参考 [GitLab 文档](https://docs.gitlab.com/ee/integration/openid_connect_provider.html#shared-information) +* GitHub 在此问题上与 GitLab 相似。 +* 如果通过 OpenID Connect 连接 GitLab/GitHub，目前最佳方案是使用 Dex 作为桥接。 +* 也可以通过 Kubernetes Webhook 认证的方式连接 GitLab / GitHub，但是不在此文档讨论的范围内。 +::: + +下图描述了使用 Dex 连接 Identity Provider 时的认证过程，使用 Dex 连接 Identity Provider 的情况下，Kubernetes Authenticate 安装向导将引导您： + +* 配置 Github、Gitlab +* 安装 Dex 到当前 Kubernetes 集群 +* 配置 Kuboard OIDC 参数 +* 配置 Kubernetes OIDC 参数 +* 为 User/Group 授权 + +

+ Kubernetes教程-OpenID Connect +

+ +##### 配置GitLab Application + +如果选择 GitLab 作为 Identity Provider： + +* 需要在 GitLab 中为 Dex 创建 Application，此时，RedirectURL 参数请从 Kubernetes Authenticate 安装向导的界面上获取，Scopes 请至少选择 `openid`、`read_user` 这两个 scope，如下图所示， +* 完成 GitLab Application 创建后，需要将 `Client ID`、`Client Secret` 两个字段回填到 Kubernetes Authenticate 安装向导。 + +![Kubernetes - OIDC - GITLAB](./install.assets/image-20200201180554307.png) + +##### 配置 GitHub Application + +* 请根据向导的提示，在 GitHub 中创建 OAuth Apps，并将 `Client ID`、`Client Secret` 两个字段回填到 Kubernetes Authenticate 安装向导。 + +#### 直连 Identity Provider + +直连 Identity Provider 时，已经验证的 Identity Provider 有： + +* [keycloak](https://www.keycloak.org/) +* 安装在其他 Kubernetes 集群的 Dex + * 某些情况下，企业可能管理多个 Kubernetes 集群，通过直连 Identity Provider 的形式，您只需要在一个 Kubernetes 集群上安装 Dex，其他集群共用这一个 Dex 服务。（每个集群各自安装一个 Dex 也未尝不可，但是，此时如果需要通过 Dex 调整后端 Identity Provider 的配置时，需要多个集群都修改一遍。） + +下图描述了直连 Identity Provider 时，用户认证的过程。此时，Kubernetes Authenticate 安装向导将引导您： + +* 配置 Kuboard OIDC 参数 +* 配置 Kubernetes OIDC 参数 + + + + +

+ Kubernetes教程-OpenID Connect +

+ +### 安装Dex + +Kubernetes Authenticate 安装向导中，请按照如下步骤完成 Dex 的安装： + +* 填写参数，如下图所示： + + 此步骤中的参数都无需修改，因为在前一个步骤 ***准备*** 环节，已经填写了，其他的参数由 Kubernetes Authenticate 安装向导为您生成。 + + 如果您希望多个 Kubernetes 集群都使用这一个 Dex 实例，请在下图表单中新增一个 Dex Client 的信息。 + + ![Kubernetes - OpenID Connect - Dex](./install.assets/image-20200201181823835.png) + +* 保存上图表单后，点击 **安装** 按钮 + + Kubernetes Authenticate 安装向导将在此 Kubernetes 集群安装 Dex，如需要了解具体安装的内容，可在安装过程中预览 Dex 的安装文件，也可以参考 [Dex](https://github.com/dexidp/dex) 的文档，已了解更多关于 Dex 的知识。 + +* 完成 Dex 安装后，Kubernetes Authenticate 安装向导将引导您确认一些信息，点击 ***已确认*** 按钮，可进入下一个步骤，**设定 Kuboard OIDC** + +### 设定Kuboard OIDC + +#### 填写 Kuboard OIDC 参数表单 + +* 设定 Kuboard OIDC 参数时，可以选择两种认证方式： + + * 授权码方式 + * 授权码方式下，Kuboard 将引导用户跳转（重定向）到 Identity Provider 的登录界面，用户在 Identity Provider 的登录界面输入用户名密码之后，再被（重定向）到 Kuboard 的界面，此时 Kuboard 获得包含用户身份信息的 Token。 + * 关于授权码方式的介绍，可参考 [OAuth 2.0 的四种方式](http://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html)。 + * 密码方式 + * 密码方式下，用户直接在 Kuboard 登录界面输入用户名密码，Kuboard 界面将认证请求发送到 Identity Provider 的服务接口，直接获得包含用户身份信息的 Token。 + * 密码方式已验证的 Identity Provider 有： + * 直连 [keycloak](https://www.keycloak.org/) + * 需要连接其他 Identity Provider 的用户，请 [联系 Kuboard 团队](https://kuboard.cn/support/) + * 关于授权码方式的介绍，可参考 [OAuth 2.0 的四种方式](http://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html)。 + +* 设定 Kuboard OIDC 参数时，oidc 相关的主要参数有 `issuer-url`、`client-id`、`client-secret`、`username-claim`、`username-prefix`、`groups-claim`、`groups-prefix`。这些参数与 Kubernetes OpenID Connect 的配置参数存在一一映射的关系，关于这些参数的详细说明，请参考 [Kubernetes OIDC 参数说明](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#configuring-the-api-server) + + > 当您使用 Dex 连接 Github、GitLab 时，Kubernetes Authenticate 安装向导为您默认生成此表单的参数，无需修改，直接保存即可。 + +#### 应用 Kuboard OIDC 参数 + +保存 Kuboard OIDC 参数的表单以后，点击 ***应用 Kuboard OIDC 配置*** 的按钮，Kubernetes Authenticate 安装向导将对 Kubernetes 集群完成如下变更： + +* 创建一个 ConfigMap ***kube-system/kuboard-authenticate-config*** ，将 Kuboard OIDC 参数保存到此表单中。 + +* 更新 Deployment ***kube-system/kuboard*** 的环境变量 `OIDC_USSER`，如下所示： + + ```yaml + 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 登录界面上在用户未登录时，就需要使用这些参数）。 + +#### 检查 Identity Provider 是否可访问 + +将 Kuboard OIDC 参数应用到集群之后，Kubernetes Authenticate 安装向导将引导您检查这些参数的应用结果，您可能需要多点击几次刷新按钮才能看到最终的成功结果，因为 Kuboard Deployment 的环境变量修改之后，会重新启动一个新的 Kuboard Pod，新 Pod 启动之后，才能生效。 + +在验证 Kuboard 可以访问 Identity Provider 之后，点击 ***下一步*** 进入 **设置 Apiserver** 的环节。 + +### 设置Apiserver + +设置 Apiserver 时，Kubernetes Authenticate 安装向导将引导您完成如下步骤： + +* 确保 Apiserver 与 Identity Provider 的连通性； +* 配置 Kubernetes apiserver 的启动参数； + * 启动参数的修改方法请参考 [修改 apiserver 启动参数](/install/faq/apiserver-params.html) +* 验证 Kubernetes apiserver 的 oidc 启动参数与 Kuboard OIDC 参数配置一致。 + +在完成 Apiserver 参数的配置之后，点击 ***下一步*** 进入 **授权** 环节。 + +> 到此为止，Kuboard 的登录界面已经可以引导您使用您配置的 OpenID Connect Identity Provider 进行用户认证，且，Kubernetes apiserver 也能识别登录后的用户身份。但是，您仍然不能进入 Kuboard 界面，或对 Kubernetes 执行任何操作，因为，您还没有为用户/用户组授权。 + +### 为User/Group授权 + +您可以在 Kuboard 界面中完成对用户/用户组的授权，而无需编写 ClusterRole、Role、ClusterRoleBinding、RoleBinding 等对象的 yaml 文件。 + +请记住，此时有如下限制： + +* 由于 Kubernetes 不管理 User、UserGroup，且可以对接多种类型的 Identity Provider，Kuboard 在对用户、用户组授权时，不能查询用户列表、用户组列表（Kuboard 界面上只能显示 ClusterRoleBinding、RoleBinding 中出现了的用户、用户组的名字）； +* 您需要自行确保授权用户、用户组在 Identity Provider 中存在； +* 您需要在 Identity Provider 中维护用户、用户组之间的映射关系。 + +参考 [使用Kuboard管理ServiceAccount及RBAC](/learning/k8s-advanced/sec/kuboard.html) + +::: tip kubectl + +由于 Kubectl 是一个命令行工具，没有图形化 Web 界面，不能发起和完成 OIDC 认证流程（不能接收 OAuth 2 授权码等认证流程中的 web url 回调），完成此配置之后，如果要使用 Github、GitLab 等 Identity Provider 中的账号登录 Kubectl，您需要先登录 Kuboard，然后在 Kuboard 的当前用户界面上获得 kubectl 的配置参数，方可使用 kubectl 。 + +::: + +## 下一步 + +至此，您已经可以使用 GitHub、GitLab等 Identity Provider 中的账号登录 Kuboard / Kubectl。下一步，您可以： + +* 为不同的团队分配 kubernetes 名称空间，并授权他们只能在自己的名称空间内工作。 diff --git a/learning/k8s-advanced/sec/authenticate/readme.md b/learning/k8s-advanced/sec/authenticate/readme.md new file mode 100644 index 0000000..a147a47 --- /dev/null +++ b/learning/k8s-advanced/sec/authenticate/readme.md @@ -0,0 +1,89 @@ +--- +vssueId: 180 +layout: LearningLayout +description: Kubernetes教程_除了ServiceAccount以外，Kubernetes不提供任何形式的用户认证方式，如果需要使用用户名密码登录Kubernete/Kuboard，可以通过OpenID Connect、Webhook Token等形式进行用户认证 +meta: + - name: keywords + content: Kubernetes 教程,Kubernetes 授权,Kubernetes authentication,Kubernetes用户名密码 + +--- + +# 用户认证概述 + + + +> 参考文档： [Authenticating](https://kubernetes.io/docs/reference/access-authn-authz/authentication/) + +## Users in Kubernetes + +所有的 Kubernetes 集群都有两类用户：Kubernetes 管理的 Service Account 和普通用户。 + +普通用户由 Kubernetes 集群之外的独立服务管理，例如 keycloak、LDAP、OpenID Connect Identity Provider（Google Account、MicroSoft Account、GitLab Account）等。此类服务对用户的注册、分组、密码更改、密码策略、用户失效策略等有一系列管控过程，或者，也可以简单到只是一个存储了用户名密码的文件。Kubernetes 中，没有任何对象用于代表普通的用户账号，普通用户也不能通过 API 调用添加到 Kubernetes 集群。 + +与普通用户相对，[Service Account](/learning/k8s-advanced/sec/sa-admin.html) 是通过 Kubernetes API 管理的用户。Service Account 是名称空间级别的对象，可能由 ApiServer 自动创建，或者通过调用 API 接口创建。Service Account 都绑定了一组 `Secret`，Secret 可以被挂载到 Pod 中，以便 Pod 中的进程可以获得调用 Kubernetes API 的权限。 + +对 API Server 的每次接口调用都被认为是： +* 由一个普通用户或者一个 Service Account 发起 +* 或者是由一个匿名用户发起。 + +这意味着，集群内外的任何一个进程，在调用 API Server 的接口时，都必须认证其身份，或者被当做一个匿名用户。可能的场景有： +* 集群中某一个 Pod 调用 API Server 的接口查询集群的信息 +* 用户通过 kubectl 执行指令，kubectl 调用 API Server 的接口完成用户的指令 +* 用户通过 Kuboard 界面管理集群，Kuboard 调用 API Server 的接口实现界面上的功能 + +::: tip 授权 +* **认证过程** 指的是 API Server 如何识别发起 API 请求的用户（进程）的身份； +* **授权过程** 指的是 API Server 在识别请求发起者身份之后，判断发起者是否可以执行该接口请求。 +::: + +## 认证策略 + +Kubernetes 的认证策略（Authentication Strategies）是：通过 authentication plugin 认证发起 API 请求的用户身份，认证方式有 client certificates、bearer tokens、authenticating proxy、HTTP basic auth。当 API Server 接收到 HTTP 请求时，authentication plugin 会尝试将如下属性附加到请求： +* **Username**：唯一标识用户的一个字符串。例如 `kube-admin` 或者 `jane@example.com` +* **UID**：唯一标识用户的一个字符串，相较于 username，提供更强的一致性和唯一性。（某些 Identity Provider 可能允许用户更改 username） +* **Groups**：一组字符串，标识用户所属的用户组 +* **额外字段**：Key,Value 都是 String 的 Map，包含一些 对 [authorizer](../authorizer/readme.html) 可能有用的信息 + +上述所有的字段对认证系统来说都是透明的，且只对 [authorizer](../authorizer/readme.html) 有意义（authentication plugin 将认证结果中的某些字段赋值到上述字段中，认证系统只是按照自己的方式正常工作，并不知道上述这些字段的存在）。这使得 Kubernetes 可以同时支持多种认证方式，在实际工作中，您通常应该至少配置两种认证方式： +* Service account tokens 用于认证 Service Account， +* 至少另外一种认证方式用于认证普通用户。 + +当多个认证模块被启用时，第一个成功对请求进行认证的模块将终止认证过程。API Server 并不确保认证模块的调用顺序。 + +Group `system:authenticated` 将被包含到所有已认证用户的 `Groups` 字段中。 + +Kubernetes 还可以使用 [authenticating proxy](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#authenticating-proxy) 或者 [authentication webhook](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 集成其他的认证协议（例如：LDAP、SAML、Kerberos、alternate x509 shcemes 等）。 + +具体来说，Kubernetes 支持的认证方式有： +* [X509 Client Certs](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs) +* [Static Token File](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#static-token-file) +* [Bootstrap Tokens](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#bootstrap-tokens) +* [Static Password File](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#static-password-file) +* [Service Account Tokens](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens) Kuboard v1.0.0 +* [OpenID Connect Tokens](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#openid-connect-tokens) Kuboard v1.0.6-beta.7 +* [Webhook Token Authentication](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) +* [Authenticating Proxy](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#authenticating-proxy) + +## Kuboard 认证方式 + +Kuboard 支持两种形式的认证： +* Service Account Kuboard v1.0.0 + * 在任意 Kubernetes 集群安装 Kuboard 之后，默认的 Kuboard 认证登录方式 + * 登录 Kuboard 后，在当前用户信息页可以获得使用当前用户身份登录 kubectl 的配置参数 +* OpenID Connect Kuboard v1.0.6-beta.7 + * 在任意 Kubernetes 集群安装 Kuboard 之后，通过 [OpenID Connect 配置向导](./install.html) 可以激活此认证登录方式 + * 可以直连 OpenID Connect Provider，例如 keycloak + * 可以通过 [Dex](https://github.com/dexidp/dex) 连接更多类型的 Identity Provider + * 已经验证的有： + * github.com + * Github Enterprise + * gitlab.com + * GitLab CE + * GitLab Enterprise + * 正在验证的有： + * LDAP + * 通过 OpenID Connect 登录 Kuboard 后，在当前用户信息页可以获得使用当前用户身份登录 kubectl 的配置参数 + +上述两种认证方式可以并存，可以通过 Dex 同时连接多个 Identity Provider。Service Account的认证方式为 Kubernetes 内置认证方式，任何情况下都是可用的。OpenID Connect 依赖于集群之外的 Identity Provider 服务，即使在 Identity Provider 服务不可用的情况下，Kubernetes 仍然可以正常启动和工作，可以通过 Service Account 登录 Kuboard / Kubernetes，待 Indentity Provider 服务可用之后，就可以使用 OpenID Connect 登录 Kuboard / Kubernetes。 + +Kubernetes 的上述特性不会为系统引入额外的高可用故障点。 diff --git a/learning/k8s-advanced/sec/authorizer/readme.md b/learning/k8s-advanced/sec/authorizer/readme.md new file mode 100644 index 0000000..e69de29 diff --git a/support/change-log/change-log-on-the-way.md b/support/change-log/change-log-on-the-way.md index 90f6a01..2f23830 100644 --- a/support/change-log/change-log-on-the-way.md +++ b/support/change-log/change-log-on-the-way.md @@ -2,11 +2,21 @@ Kuboard v1.0.x 的更新说明 + + + +必须完成： +* 文档 +* 教程 + +* 群反馈 Pod 列表界面出现重复数据的问题 + ------------------ * 按名称空间查看 Events * 按名称空间查看 top pods -* 修改 metadata.labels +* 修改 metadata.labels kuboard v1.0.7 * 支持 Headless Service +* 在服务器端配置 openid connect 的 client_secret 以增强安全性 * 安装文档中，将 daocloud 的镜像地址修改为阿里云的镜像地址 * 日志界面支持 ctrl + F @@ -40,3 +50,10 @@ Kuboard v1.0.x 的更新说明 * 显示 Deployment/StatefulSet/DaemonSet 的事件 * 控制台/日志界面，按 名称空间/工作负载/Pod/容器 进行切换 * StatefulSet 在 available 数与 replicas 数不一致时，链接到帮助提示 + + +# 用户认证相关 + +* Gitlab + * GitLab 的 idtoken 中只包含 sub 字段（此处的含义为用户的ID），没有用户名和邮箱地址等信息，因此不能直接和 Kubernetes OpenID Connect 对接 + * https://docs.gitlab.com/ee/integration/openid_connect_provider.html#shared-information diff --git a/support/change-log/v1.0.x.md b/support/change-log/v1.0.x.md index 686d0d5..8e2f6de 100644 --- a/support/change-log/v1.0.x.md +++ b/support/change-log/v1.0.x.md @@ -14,6 +14,43 @@ description: 本文描述了Kuboard_v1.0.x的版本变更说明 Kuboard v1.0.x 的更新说明 +## v1.0.6-beta.7 + +**发布日期** + +2020年2月1日 + +**新特性** +* OpenID Connect + * OpenID Connect 安装向导 + * 授权码（Authorization Code Grant）方式登录 + * 通过Dex对接，已验证如下 identity provider + * github + * gitlab + * 直接对接，已验证如下 identity provider + * Keycloak + * 密码（Client Credentials Grant）方式登录 + * Keycloak +* User/Group + * SelfInfo 增加对 User/Group 的支持 + * SelfInfo 可获得当前登录 User 的 kubectl 配置 + * 查看名称空间中被授权的 User/Group 列表 + * 查看名称空间中 User/Group 的被授权明细 + * 为 User/Group 增加新的 RoleBinding/ClusterRoleBinding + +**优化** +* ConfigMap --> 优化查看ConfigMap时，字体行距过大的问题 +* 页头 --> 必须具备 '' - 'namespaces' - 'list' 权限，才能导航到集群概览页 +* 工作负载编辑器 --> ImagePullSecrets --> 增加对此字段的表单校验 + +**Bug修复** +* 集群概览页 --> 登录成功后，当 metris-server 已安装时，存在需要刷新页面才显示 top nodes 的问题 +* 工作负载编辑页 --> ImagePullSecrets 不能包含空值 +* Secret详情窗口 + * TLS --> tls.key 字段显示内容错误 + * 再次打开删除 Secret 的对话框时，被删除的 Secret 名称应该更新 + + ## v1.0.6-beta.6 **发布日期**