andre/kuboard-press
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

kuboard v1.0.6-beta.7 支持 Kubernetes Authenticate 安装向导

Browse Source
This commit is contained in:
huanqing.shao
2020-02-01 21:43:19 +08:00
parent 88f65b64d5
commit b2ece220dd
12 changed files with 537 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
.vuepress/config-sidebar.js
View File

@ -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',
]
},
]
},
{

142
install/faq/apiserver-params.md Normal file
View File

@ -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 节点上都修改该文件，并使各节点上的参数保持一致。
:::

BIN
learning/k8s-advanced/sec/authenticate/install.assets/image-20200201152914338.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 289 KiB

BIN
learning/k8s-advanced/sec/authenticate/install.assets/image-20200201160933419.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 323 KiB

BIN
learning/k8s-advanced/sec/authenticate/install.assets/image-20200201174418018.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 194 KiB

BIN
learning/k8s-advanced/sec/authenticate/install.assets/image-20200201180554307.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 361 KiB

BIN
learning/k8s-advanced/sec/authenticate/install.assets/image-20200201181823835.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 425 KiB

229
learning/k8s-advanced/sec/authenticate/install.md Normal file
View File

@ -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 安装向导
<AdSenseTitle/>
本文描述了如何为已有 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 <Badge type="warning">计划中</Badge>
当使用 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 授权
<p style="max-width: 800px;">
<img src="./install.assets/image-20200201152914338.png" alt="Kubernetes教程-OpenID Connect"/>
</p>
##### 配置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 参数
<p style="max-width: 500px;">
<img src="./install.assets/image-20200201174418018.png" alt="Kubernetes教程-OpenID Connect"/>
</p>
### 安装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 名称空间，并授权他们只能在自己的名称空间内工作。

89
learning/k8s-advanced/sec/authenticate/readme.md Normal file
View File

@ -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用户名密码
---
# 用户认证概述
<AdSenseTitle/>
> 参考文档： [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) <Badge>Kuboard v1.0.0</Badge>
* [OpenID Connect Tokens](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#openid-connect-tokens) <Badge>Kuboard v1.0.6-beta.7</Badge>
* [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 <Badge>Kuboard v1.0.0</Badge>
* 在任意 Kubernetes 集群安装 Kuboard 之后，默认的 Kuboard 认证登录方式
* 登录 Kuboard 后，在当前用户信息页可以获得使用当前用户身份登录 kubectl 的配置参数
* OpenID Connect <Badge>Kuboard v1.0.6-beta.7</Badge>
* 在任意 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 的上述特性不会为系统引入额外的高可用故障点。

0
learning/k8s-advanced/sec/authorizer/readme.md Normal file
View File

19
support/change-log/change-log-on-the-way.md
View File

@ -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

37
support/change-log/v1.0.x.md
View File

@ -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
**发布日期**