K8S入门学习(七)：集群编排工具之 Kuboard V3 版本(二)-CFANZ编程社区

一、用户、组、角色相关

1.1、角色绑定涉及的概念

Kuboard V3 里面的角色绑定，涉及以下几个概念：

用户：Kuboard 定义的单创建的账号，为绑定具体角色之前与任何K8S集群无关
用户组：Kuboard 定义的用来关联用户账号的 (非必须的)，通常以用户组去进行角色绑定
角色：分为两种 --- 全局集群角色和集群级别角色
- 全局集群角色：Kuboard 默认全局集群角色五个里面只给到三种 --- administrator、viewer 、sso-user ，权限依次是由大到小
- 集群级别角色：用户或用户组在绑定到指定的K8S集群时拥有的角色，也是上面三种，即以何种身份去访问和操作指定的某个K8S集群

1.2、集群角色的联系与区别

全局集群角色绑定：
- 影响相关用户在登录 Kuboard 管理平台后，使用平台上自带的有关的功能
- 进行 administrator、viewer 角色绑定后，集群级别的角色绑定没有任何意义
- 如果不使用第二阶段授权的方案，全局集群只进行 sso-user 角色绑定就失去了意义，因为没有任何操作权限
- 进行二阶段授权的时候，要使用全局集群的 sso-user 角色，但不直接进行全局集群的任何角色绑定
集群级别角色绑定：
- 集群角色绑定 administrator、viewer 两角色时，全局级别角色绑定失去意义
- 没有导入K8S集群时，无法进行集群级别角色的绑定，此时的全局集群角色绑定，没有任何意义
- 第二阶段授权方案的实现，必须依赖于全局集群角色中的 sso-user 角色，将集群基本角色绑定为 sso-user 角色

二、集群的角色相关

2.1、全局集群角色有哪些

administrator： 管理员
viewer： 只读角色
sso-user： SSO 用户
authentiated： 已认证用户
anonymous： 匿名用户

2.2、集群级别角色相关：

面向用户角色的 UserAccount 是给 kubernetes 集群给外部用户使用的，是全局性的，在集群所有名称空间中，名称具有唯一性。
UserAccount 账号通过角色绑定，在名称空间范围内被授予权限，使用 RoleBindings 的方法，在指定名字空间中授予的相应角色。
主要角色有三种：
- admin： 允许管理员访问权限，旨在使用 RoleBinding 在名字空间内执行授权。可授予对名字空间中的大多数资源的读/写权限，包括创建角色和角色绑定的能力。此角色不允许对资源配额或者名字空间本身进行写操作。
- edit： 允许对名字空间的大多数对象进行读/写操作。此角色不允许查看或者修改角色或者角色绑定。此角色可以访问 Secret，以名字空间中任何 ServiceAccount 的身份运行 Pod，所以可以用来了解名字空间内所有服务账户的 API 访问级别。
- view： 允许对名字空间的大多数对象有只读权限。它不允许查看角色或角色绑定。不允许查看 Secret 。

三、不同角色绑定相关

3.1、角色绑定之后的作用体现

用户或者用户组单独绑定了全局集群角色中 administrator 角色后，对指定的集群可以使用 kuboard-admin 或者 kuboard-viewer 的身份进行访问，拥有相当集群级别的 admin 的权限
用户或者用户组单独绑定了全局集群角色中 viewer 角色后，对指定的集群可以使用 kuboard-viewer 的身份，对指定的集群有相当集群级别的 view 的权限
用户或者用户组单独绑定了全局集群角色中 sso-user 角色后，对指定的集群没有任何权限
用户或者用户组单独绑定了集群级别角色中 administrator 角色后，对指定的集群可以使用 kuboard-admin 或者 kuboard-viewer 的身份进行访问，拥有相当集群级别的 admin 的权限，此时全局集群角色中有关本集群的绑定失去意义，涉及其它集群的部分任然有效
用户或者用户组单独绑定了集群级别角色中 viewer 角色后，对指定的集群可以使用 kuboard-viewer 的身份，对指定的集群有相当集群级别的 view 的权限，此时全局集群角色中有关本集群的绑定失去意义，涉及其它集群的部分任然有效
用户或者用户组单独绑定了集群级别角色中 sso-user 角色后，对于指定的集群没有任何权限
用户或者用户组，不与全局集群角色绑定同时也不与集群级别角色绑定，对于指定的集群没有任何权限，导入的集群都查看不到

总结：

1、除非使用二阶段授权的机制，不然同时进行全局集群角色的绑定和集群级别角色绑定，没有任何意义

2、如果单独使用的话，建议使用集群级别角色绑定就可以了

3.2、有哪些方式的角色绑定

在第一节里面提到过，相关的绑定涉及用户、用户组、全局集群角色、集群级别角色，对如不同的使用场景和公司的实际情况，具体实现方式有如下：

用户和全局集群角色进行绑定
用户和集群级别角色进行绑定
用户关联到用户组，用户组和全局集群角色进行绑定
用户关联到用户组，用户组和集群级别角色进行绑定

四、用户角色绑定

4.1、用户只绑定全局集群角色

全局集群角色的三个集群角色：administrator 、viewer 、sso-user , 权限依次是从大到小。如下图：

定义三个用户，分别是：laoliu 、laowang 、xiaojiejie 。进行全局角色绑定，将用户关联到全局集群角色下面的具体角色。

账号 laoliu 绑定的全局角色为 viewer
账号 laowang 绑定的全局角色为 sso-user
账号 xiaojiejie 绑定的全局角色为 administrator

绑定完成后如下图所示：

在不同的浏览器用三个账号登录 Kuboard 平台，不难发现其不同点：

1、下面是在 Kuboard 平台上体现出来的不同之处：左边操作按钮栏对应的数量多少不同

2、虽然没有进行具体的集群角色绑定，但是还是可以对导入的具体集群有相关的访问权限

全局集群角色绑定了 administrator 角色的 xiaojiejie 账号使用 kuboard-admin 的身份、对导入的集群有 admin 的权限 (此处未截图展示)
全局集群角色绑定了 viewer 角色的 laoliu 账号使用 kuboard-viewer 的身份、对导入的集群拥有集群级别的 view 的权限
全局集群角色绑定了 sso-user 角色的 laowang 账号，对导入的集群没有任何权限

4.2、用户只绑定集群级别角色

再定义一个用户账号 test01，对于导入两个集群，只进行集群级别的角色绑定，分别如下:

集群 K8S-50 绑定的集群级别角色为 sso-user
集群 K8S-100 绑定的集群级别角色为 viewer

在浏览器使用 test01 账号登录 Kuboard 平台查看

集群级别绑定 administrator 角色无需测试，自然是使用的是 kuboard-admin 的身份、对集群有 admin 的权限
集群 K8S-50 绑定用户 test01 为 sso-user 角色时，对集群没有任何权限
集群 K8S-100 绑定用户 test01 为 viewer 角色时，对集群拥有 view 的权限

4.3、用户同时绑定全局集群角色和集群级别角色

1、账号名为 xiaojiejie 的全局集群角色为 administrator，再进行集群级别的具体角色绑定

集群 K8S-50 绑定的集群级别角色为 sso-user
集群 K8S-100 绑定的集群级别角色为 viewer

经过测试发现： 即全局角色为 administrator 时，集群级别角色指定为 viewer 、sso-user 也不受影响，对集群的权限保持着全局角色权限，即可以理解为角色权限降级无效

2、账号名为 laowang 的全局集群角色为 sso-user，再进行集群级别的具体角色绑定

集群 K8S-50 绑定的集群级别角色为 viewer
集群 K8S-100 绑定的集群级别角色为 administrator

经过测试发现：即全局角色为 sso-user 时，集群级别角色指定为 administrator 、 viewer 后，对导入的集群的操作权限权限果然有提升，以集群级别的角色权限为主，即可以理解为角色提升时有效

3、第三种情况，全局集群角色为 viewer 时，进行集群角色绑定时分别定义为 administrator 、sso-user 角色

其实不用做实验了，参考上面的两种情况，很容易得出结论：

集群级别角色绑定大于全局集群角色时，以集群级别角色为主，反正则以全局集群角色为主

4.4、单独用户角色绑定总结

如果涉及的账号太多的话，后面要进行绑定角色修改，操作起来很麻烦
单独使用用户进行集群角色绑定，涉及到的有两个角色，权限容易混淆或起冲突
单独的进行用户角色的绑定，不能够颗粒化到指定的集群里面的具体的名称空间

五、用户用户组角色绑定

5.1、定义用户与用户组

为了解决上面的第一问题，引入了用户组的概念

提示：

再次实验，要删除所有用户绑定的全局角色、集群角色，创建组，用户关联到组，组去绑定集群设定相关的角色
后面除非是涉及二阶段授权相关，不然不会进行全局集群角色的绑定，上面诸多实验证明了其没有意义

重新定义四个用户，分别是：laoliu 、laowang 、xiaojiejie、xiaoxianrou 。
在定义三个用户组，分别是：group01 、group02 、group03 。
group01 关联用户 xiaojiejie 。
group02 关联用户 xiaoxianrou 。
group03 关联用户 laoliu 、laowang 。

用户、用户组关联完成后如下图所示：

5.2、用户组进行角色绑定

group01 用户组进行绑定集群为 K8S-50 , 其集群级别绑定的角色为 administrator
group02 用户组进行绑定集群为 K8S-100 , 其集群级别绑定的角色为 viewer
group03 用户组进行绑定集群为 K8S-50 和 K8S-100 , 其集群级别绑定的角色为 sso-user

分别使用用户组关联的用户进行登录

group01 组关联的 xiaojiejie 用户，登录 Kuboard 后，只能看到导入的 K8S-50 集群，使用的是 kuboard-admin 的身份、对集群有集群级别的 admin 的权限

group02 组关联的 xiaoxianrou 用户，登录 Kuboard 后，只能看到导入的 K8S-100 集群，使用 kuboard-viewer 的身份、对集群拥有集群级别的 view 的权限

group03 组关联的 laoliu 、laowang 用户，登录 Kuboard 后，只能看到导入的 K8S-50 和 K8S-100 集群，但是没有任何访问权限

5.3、用户组角色绑定总结

用户组进行绑定集群级别的角色为 administrator 或 viewer 时，在所对应的集群中拥有的就是相对角色和权限
用户组进行绑定集群级别的角色为 sso-user 时，对于所有绑定的集群，没有任何访问权限

六、关于二阶段授权

第一阶段授权，定义当前用户或者用户组
- 可以访问操作哪个集群：授权对象可以是单独的用户，也可以是用户组，一般都是结合用户组来进行授权操作
- 以何种角色操作该集群：sso-user 是安装 Kuboard 时默认创建的第一阶段授权的角色，Kuboard 定义了名为 ct-as-impersonate-user 的一种资源类型，as-impersonate 翻译为冒充之意，允许与此角色关联的用户/用户组以使用 ServiceAccount kuboard-admin 扮演的身份操作 Kubernetes 集群。
第二阶段授权，定义当前用户或者用户组
- 在具体指定的集群内有何种权限：主要是以名称空间为维度，来进行权限的定义和操作的

七、具体二阶段授权操作

再次强调一下：进行二阶段授权操作，要使用到全局集群里面的 sso-user 角色，但是不需要进行任何全局集群角色的绑定操作

7.1、第一阶段授权

将用户组关联相关用户，然后将用户组进行集群级别的角色绑定，绑定到指定的集群角色为全局集群角色里面的 sso-user 角色

重新定义用户组 group03 ，关联用户 laoliu 、laowang
group03 进行集群级别的绑定，绑定具体集群 K8S-50 , 其绑定集群级别绑定的角色为 sso-user
group03 进行集群级别的绑定，绑定具体集群 K8S-100 , 其绑定集群级别绑定的角色为 sso-user

具体见下图：

可能有点好奇，第一阶段授权，不是应该在具体对应的集群里面，找到 “访问控制” --- “第一阶段授权” ，这里里面去操作的吗？

下面我们就依照这个流程去操作一下：

关于第一阶段授权的小结：

经过上面的操作会发现，其实第一阶段授权，就是将用户关联到用户组，用户组再绑定指定的集群级别角色，这里的角色是全局集群角色里面的 sso-user 角色
在上面的第四节、第五节里面，就已经说明过，用户或者用户组，在全局集群的界面里面，也能够进行集群级别角色和全局集群的角色角色的绑定操作的，两个是没有操作的结果是没有区别的，方式不同而已

第一阶段授权后，访问绑定的集群看看是什么情况 --- 在绑定的集群里面没有任何访问权限

7.2、第二阶段授权

选择导入的集群 “K8S-50” , 左边栏里面选择 “访问控制” --- “第二阶段授权” --- “用户组” --- “为新Group授权” ，选择用户组 “group03”
当前的名称空间选项，选择名称空间 “web” ，在下面的 “RoleBinding” 选项点击 “添加”
新的弹出框里面再一次选项 “web” 名称空间，在后面 “关联 ClusterRole / Role” 栏里面 “name” 进行选择
选择的 “ClusterRole” ，三个选项 “admin”、 “edit” 、 “view” 均可，建议选择权限最小的 “view”

同样的方法，集群 “K8S-50” 关联 “group03“ 全局集群角色为 sso-user ，对应绑定的集群级别空间为 ”web2“

同样的方法，集群 “K8S-100” 关联 “group03“ 全局集群角色为 sso-user ，对应绑定的集群级别空间为 ”default“

7.3、访问集群进行验证

八、集群角色绑定信息查看

8.1、全局集群角色绑定相关


[root@node200 ~]# docker ps | grep kuboard
ff706038dab8        eipwork/kuboard:v3.3.0.0   "/entrypoint.sh"    47 hours ago        Up 47 hours         443/tcp, 0.0.0.0:10081->10081/tcp, 0.0.0.0:8000->80/tcp   kuboardv3

[root@node200 ~]# docker exec -it ff70 /bin/bash

root@ff706038dab8:/# etcdctl get --prefix "" --keys-only | grep group
/kind/KuboardAuthClusterRoleBinding/cluster/K8S-100/group.group02.viewer
/kind/KuboardAuthClusterRoleBinding/cluster/K8S-100/group.group03.sso-user
/kind/KuboardAuthClusterRoleBinding/cluster/K8S-50/group.group01.administrator
/kind/KuboardAuthClusterRoleBinding/cluster/K8S-50/group.group03.sso-user
/kind/KuboardAuthGlobalRoleBinding/cluster/GLOBAL/group.administrators.administrator
/kind/KuboardAuthGroup/cluster/GLOBAL/group01
/kind/KuboardAuthGroup/cluster/GLOBAL/group02
/kind/KuboardAuthGroup/cluster/GLOBAL/group03
/kind/KuboardAuthUserInGroup/cluster/GLOBAL/laoliu.group03
/kind/KuboardAuthUserInGroup/cluster/GLOBAL/laowang.group03
/kind/KuboardAuthUserInGroup/cluster/GLOBAL/xiaojiejie.group01
/kind/KuboardAuthUserInGroup/cluster/GLOBAL/xiaoxianrou.group02

8.2、集群级别角色绑定查看

在 Kuboard 的 UI 界面查看绑定的信息

进行相关集群里面查看绑定相关的信息


[root@node50 ~]# kubectl get rolebinding -A | grep web
web               group03-rolebinding-yiznx        ClusterRole/admin                   13m
web2              group03-rolebinding-yyhnk        ClusterRole/edit                    11m


[root@node100 ~]# kubectl get rolebinding -A | grep default
default       group03-rolebinding-bpnw8             ClusterRole/admin                  14m

8.3、Etcd 数据库信息查看

在宿主机上查看数据文件大小


[root@node200 snap]# cd /data/kuboard-data/
[root@node200 kuboard-data]# ll
total 4
drwx------ 3 root root 20 Sep 26 10:06 etcd-data
-rw-r--r-- 1 root root 33 Sep 26 10:06 kuboard_agent_key
drwxr-xr-x 6 root root 53 Sep 26 10:06 questdb-data

[root@node200 kuboard-data]# cd etcd-data/member/snap/
[root@node200 snap]# ll
-rw------- 1 root root 8458240 Sep 28 09:31 db

[root@node200 snap]# ls -lrth
total 4.3M
-rw------- 1 root root 8.1M Sep 28 09:32 db

进入到数据库里面查看数据大小



root@ff706038dab8:/# ETCDCTL_API=3 etcdctl --endpoints="http://127.0.0.1:2379" --write-out=table endpoint status
+-----------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
|       ENDPOINT        |        ID        | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+-----------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| http://127.0.0.1:2379 | 59a9c584ea2c3f35 |  3.4.14 |  4.3 MB |      true |      false |         2 |      11540 |              11540 |        |
+-----------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+