【K8S运维知识汇总】第4天6：dashboard分权举例

dashboard可以用令牌的方式进行登陆

用令牌登陆就需要kubectl describe secret，获得这个令牌

实际上是kubernetes-dashboard-admin这个service account 服务账号产生的
一个服务账号一定是对应唯一的服务账号的secret，secret秘密配置

kubernetes-dashboard-admin这个service account 服务账号产生的，这个服务账号里就有令牌复制出来

令牌复制到这里来登陆

就获得了kubernetes-dashboard-admin这个service account对应的角色，角色是cluster admin，cluster-admin所绑定的权限是

集群管理员
官方给了role和rolebinding，拷贝一下

在运维主机上

还有一个service account

复制到最上面

先去执行rbac-minimal.yaml
里面其实创建了一个service account ，名字是 kubernetes-dashboard

定义了一个role，叫做kubernetes-dashboard-minimal，给了一堆比较小的权限rules

最后做了角色绑定，这个权限相对比较小

先创建出来

修改使用的服务账户

再去apply dp.yaml，相当于重新配置一下了

滚动升级，先拉起一个正常了，再把原来的干掉

现在有两个service account，两个令牌一个 kubernetes-dashboard account， kubernetes-dashboard-admin的account

这张令牌

权限不够就各种报错，也就是官方给的dashboard-minimal权限是非常小的

去拿admin的令牌，试试能否登陆进去

能够登陆进来，你有令牌就调整根据这个service进来的account的角色，默认给的是最小minimal的角色

换成1.8.3可能更加清楚

1.8.3的镜像也在harbor仓库里，等它起来就行

skip就是用dashboard的pod默认的服务账户（现在用的是minimal）

所以skip进去以后没有权限

dashboard这样 规定权限，可以开发使用，测试使用，也就是不光运维可以用

这个是集群管理员的权限

这张令牌就需要你好好保管，说白了就是集群管理员

如果要限制权限，就需要做一个service account clusterRole或者role都行，用service account和cluster role做一个绑定。K8S控制权限就是基于访问控制来控制的

一个pod起来只能对应一个service account，但是这个service account可以对应不同的权限。
pod实际上是承载了service account，service account可以对应不同的角色（既可以是集群管理员，又可以是观察者的角色）rbac就是账户和权限不产生直接关系，而是角色和权限产生关系。通过角色这个中间层，把账户和权限隔离开了

这里改回admin，后面方便做集群管理

生产中建议把skip按钮去掉
重新configure、

现在直接skip进去就是用的集群管理员admin，什么权限都有，这样非常不好