动手搓一个kubernetes管理平台(2)-后端权限设计

授权和认证

1. 权限分类

由于用户需要操作kubernetes,所以权限分类起码需要2套,即平台的权限和集群的权限管理,前者用于管理平台,如用户的添加,报表的查看,日志的审计等等,后者用于集群管理,需要和kubernetes的rbac进行关联.

  • 平台权限

平台的权限管理使用的方法比较多,如基于url进行授权,基于Priority进行属性授权等等,方法很多,由于该平台对于基本权限的需求并不复杂,所以使用基本的RBAC的逻辑进行权限划分,即基于资源和角色进行权限划分。

用户
角色
资源+动作

每个用户绑定多个 role, 每个role是 多个资源+动作的集合,如url是xxx.com/platform/cluster/update, 其中cluster就是资源,update就是动作,基于这种组合方式,实现平台的权限划分。

  • 集群权限

众所周知,kubernetes的RBAC权限很经典,但同时也挺复杂,传统的dashboard做法是提供一个管理员token或者kubeconfig进行直连,所有人都是这个权限,重一点的 ,比如rancher,会基于kubernetes的rbac 创建权限,颗粒度很细,但是代价就是每个用户会独享一个service account,假设一家公司运维人员成百上千,集群内就会有一堆service account,偶尔再来个离职入职,不敢想不敢想,所以,在设计集群权限的时候,我们将复杂的权限分类抽象出3大类,即viewer, ops, admin权限,并创建好对应的clusterrole 和service account,最终将用户绑定到service account上

用户
ServiceAccount
ClusterRole
  • 将权限转换成token

基于jwt的概念,将两者的权限分为2个字段,存入profile, 然后基于jwt的原理, 将权限信息转换成token,作为接口的权限认证。

kube-perm

2. 动态菜单

因为前端可以看到的菜单信息和需要和后端绑定的,所以基于前端进行静态配置不太合理,基于这个考虑,需要在后端开发一个接口,用于获取前端的菜单,然后由前端对返回进行渲染,实现不同权限看到不同的菜单的效果。

3. Profile

上述权限的核心其实就是Profile,用户的实时权限都是存在Profile里的,所以在设计Proflie的时候需要谨慎。

// 基础用户属性
type ResourceBase struct {
	Description string `json:"description"`
	CreateAt    string `json:"createat"`
	UpdateAt    string `json:"updateat"`
	BuiltIn     bool   `json:"builtin"`
	UUID        string `json:"uuid"`
}

// 平台策略
type PlatFormRulePolicy struct {
	ResourceName string   `json:"resourcename"`
	Verbs        []string `json:"verbs"`
}

// 平台角色
type PlatFormRole struct {
	RoleName  string                `json:"rolename"`
	CreatedBy string                `json:"createdby"`
	Rules     []*PlatFormRulePolicy `json:"rules"`
	v1.ResourceBase
}

// 集群绑定关系
type ClusterRoleBinding struct {
	UserName        string   `json:"username"`
	UserUUID        string   `json:"useruuid"`
	ClusterRoleUUID string   `json:"clusterroleuuid"`
	ClusterRoleName string   `json:"clusterrolename"`
	ClusterUUID     string   `json:"clusteruuid"`
	Namespaces      []string `json:"namespaces"`
}

// 用户Profile
type UserProfile struct {
	Name                  string                                           `json:"name"`
	UUID                  string                                           `json:"uuid"`
	NickName              string                                           `json:"nickname"`
	Email                 string                                           `json:"email"`
	Language              string                                           `json:"language"`
	ResourcePermissions   []*v1RoleStruct.PlatFormRole                     `json:"resourcePermissions"`
	KubernetesPermissions []*v1ClusterRoleBindingStruct.ClusterRoleBinding `json:"kubernetespermissions"`
	Token                 string                                           `json:"token"`
	LoginTime             string                                           `json:"logintime"`
	jwt.RegisteredClaims
}

上述profile保存了用户的基本信息,权限信息,以及jwt签名后的token,一个用户对于平台和集群的所有权限,均会通过上述profile进行保存。

To Be Continued …

在梳理完权限如何设计后,便可以构建出最初版本的后端框架了。

个人公众号, 分享一些日常开发,运维工作中的日常以及一些学习感悟,欢迎大家互相学习,交流

在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值