在kubesphere 的权限管理体系中,我们将权限管理划分了三个层级, 集群级别、企业空间级别和项目和工程级别,在我们的设计中:
集群级别的权限控制注重于集群资源的控制,比如集群监控,集群日志,系统用户管理等等。
企业空间级别的权限控制注重于租户资源的管理,比如企业空间下项目、工程的管理,应用模板的管理等等。
工程和项目级别的权限管理则注重于工作负载、配置、密钥、devops 流水线等项目资源的权限控制。
我们不期望通过集群角色来直接控制企业空间下、项目下的实际资源, 如果有必要则必须通过邀请协作、添加成员的方式,关联到具体层级的角色上, 这样可以更清晰对不同层级权限进行管理,而不出现穿透层级的问题。
这其中,workspaces-admin 或者说是 (企业空间管理权限)是一个设计不太合理的集群层级的权限,在我们设计中workspaces-admin 只是为了分担 cluster-admin 管理企业空间(创建、删除企业空间,企业空间下的成员维护)的工作,但为了实现企业空间的管理,该角色具备了集群中大部分资源(包括企业空间、项目两个层级)的控制权限,如果workspace
workspaces-admin 的误操作会影响到集群的稳定运行,企业空间管理权限也不是每个集群角色所必须的权限, 为了规避这样的风险,我们在2.1.1 版本 中收敛了企业空间管理权限(具有企业空间管理权限的角色不能参与到企业空间下项目协同),用户需要获取项目资源的管理权限除cluster-admin外,必须参与到项目协同之中。
上述问题中一和三是因为企业空间管理权限收敛造成的具有企业空间管理权限的角色不能参与到企业空间下项目协同,第二个问题,集群中的项目管理是为了便于集群管理员,对(不属于企业空间的)项目进行规划,用户需要获取项目资源的管理权限除cluster-admin外,必须参与到项目协同之中(加入企业空间后再参与项目协同)。
这次的权限调整确实给大家带来了不必要的困惑,角色说明文案和文档也未及时作出调整。
我们会在3.0 中对权限管理体系做一个系统化的调整,让自定义角色更易用,提供一个更清晰的权限控制体系,避免出现这种容易带来安全隐患和误解的角色。
非常感谢大家提出的宝贵问题, 我们都会去关注去思考这些问题,我们也会陆续将新的设计、代码提交到Github,如果你有不一样的想法也可以提出issue或是帖子参与讨论。