我一直在负责维护的PaaS平台引入了Kubernetes作为底层支持，可以借助Kubernetes的生态做更多的事情，这篇博客主要介绍如何为用户提供Dashboard功能，以及一些可以扩展的想法。希望读者有一定的Kubernetes使用经验，并且了解RBAC的功能。

Dashboard功能

Kubernetes原生提供了Web界面，也就是Dashboard，具体的参考可以见官方文档：https://kubernetes.io/zh/docs/ ... oard/：

安装完成后，我们一般是通过Token来使用的，不同的Token有着不同的权限。

上面所说的Token是Bearer Token，除了在界面上输入之外，你可以这么来用，通过添加header即可。

curl -H "Authorization: Bearer ${TOKEN}" https://{dashboard}/api/myresource

PaaS平台使用Dashboard简要讨论

Dashboard本身的功能是十分强大的，但是给所有人admin权限显然是不现实的。对于一个普通用户来讲，PaaS平台的将他的应用（代码）部署好并运行，他所需要关注的就只有属于他自己的项目，平台也需要做好权限控制，避免一个用户操作了另一个用户的应用。

权限系统设计

基于以上的需求讨论，平台需要做的操作就是为每个用户创建属于自己的权限提供，并限制可以访问到的资源。考虑这样的情况：

我们有一个用户A，他拥有自己的一个应用群组（G），群组中部署了一系列应用程序（a1, a2…）。在Kubernetes中，这样的群组概念我们将其映射为namespace，群组（G）<=> 用户空间（NS），我们需要控制的权限控制策略就变成了用户A在用户空间NS的权限控制。

Token分发策略

拥有了权限控制后，所需要打就是将Token分发给用户，当然这是一种极度不安全的做法，Kubernetes中的Token创建之后一般是不会改变的，分发这样的Token会有很大的安全风险，有两个方面：

1. 用户A将Token保存了下来，那么他就能不经过平台登录Dashboard，这样不利于审计工作
2. Token一旦泄露，PaaS平台很难做到反应（因为Token脱离了平台的控制，无法判断究竟是什么时候发生了泄露，也无法马上吊销这个Token），安全风险比较高

因此, 最好的做法就是不把Token交给用户，用户每次想要登录Dashboard，从平台进行跳转，跳转时携带安全信息，在Dashboard登录时，由平台自己的程序请求Token，避免经手用户。

注意：如果到这里，你没有理解上面的内容，建议回去再看一次需求，如果还是理解不了，就不要往下看了，下面只是介绍具体的实现方案。

Kubernetes权限限制

Kubernetes本身有着比较复杂的权限控制系统，设计时没必要纠结过多，按照可以给用户和不能给用户的权限进行区分就好了。我直接贴一下我的权限控制策略吧，并不一定适合每个人，只是可以做个参考。

---

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

name: xxx:xxx-group-yyy

namespace: xxx-group-yyy

rules:

# 可以查看当前NS下面的service，pod，logs，events

- apiGroups: [""]

resources: ["services", "pods", "pods/log", "events"]

verbs: ["get", "list", "watch"]

# 可以使用exec命令进入容器

- apiGroups: [""]

resources: ["pods/exec"]

verbs: ["create", "list", "watch"]

# 可以查看deployments和replicasets

- apiGroups: ["extensions", "apps"]

resources: ["deployments", "replicasets"]

verbs: ["get", "list", "watch"]

# 可以查看job，cronjob以及ingress

- apiGroups: ["batch", "extensions"]

resources: ["cronjobs", "jobs", "ingresses"]

verbs: ["get", "list", "watch"]

正如上面的注释一样，尽可能只给用户只读的权限，也许你已经发现了，甚至不需要给用户namespace的查看权限，这也是为了安全，避免用户得知其他人的namespace。

分发Token以及安全性保证

这是本篇博客的核心内容：如何使得用户可以无感知的登录到Dashboard（对用户隐藏Token）。

该方案用到的方法是：添加一层访问控制的网关，用于处理Token获取的操作，具体的流程图如下：

需要注意的有几点：

1. PaaS给出的secret_code是有时效性的，不允许用户一直用同一个secret_code进行访问
2. 网关与PaaS平台间的通信应该加密，网关必须是PaaS平台可信的
3. 网关不应该长期保存Token
4. 网关的访问最好添加OpenID校验，确保网关可以精确定位到每个用户的每次访问

1. 首先，第2步到第3步，secret_code获取之后，可以以302重定向的方式跳转至网关入口
2. 网关可以临时性的保存secret_code与Token的映射关系，既能够提升用户体验，也能有效减缓PaaS平台的压力
3. Dashbaord的webshell功能是基于websocket支持的，所以请确保你的网关可以通过websocket请求，否则终端连接后几分钟就断了，websocket可以持续几个小时那么久
4. 跳转到网关时，可以携带更多的信息，比如携带某个Pod的ID，网关就可以直接跳转到对应的Pod，用户打开webshell就很方便了

网关的实现我不做过多的说明了，只有一点建议，secret_code在跳转到网关后，马上进行校验。由于Dashboard的前端路由实现问题，secret_code最好在校验后加密放置到cookie中，实现方面的问题其他可以发邮件与我讨论。
这篇博客主要介绍了一种允许普通用户使用Dashboard的功能。在实现策略上，利用了Kubernetes的权限限制，Token隐藏的方案，该方案目前我已经加入到了我负责的PaaS平台中，稳定性方面可以满足工作需求，安全性正如博客中介绍，大家可以自行斟酌。

我很抱歉博客中字多图少，也没有给出具体的实现。首先代码实现是不重要的，其次因为是公司的代码，不方便分享，请见谅。

原文链接：https://corvo.myseu.cn/2020/12/05/2020-12-05-基于Kubernetes的PaaS平台提供dashboard支持的一种方案/，作者：corvofeng

分享

2021-09-13