linuxea:kubernetes 了解RBAC(31)

之前我们知道kubernetes的授权是用插件来实现,并且支持很多插件,并且支持很多插件同时使用,且只要通过其中一个授权检查通过则不会在进行其他插件进行检查,而后由准入控制插件后续检查。

授权插件常用有四个:节点Node,ABAC属性访问控制,RBAC,Webhook回掉机制实现授权、

RBAC

RBAC的全称是Role-based AC,在kubernetes中RBAC就是定义标准的资源:

  • Role:

operations(许可授权,在其中只要包含在内的写入的都是允许的,不能定义拒绝权限,因为没有就是拒绝权限),objects,

  • rolebinding(角色绑定)

将用户(useraccount)或者serviceaccount绑定到那个角色上,让用户扮演那个角色

其中role和rolebinding有两个级别

在kubernetes中资源分属两种级别,集群名称空间,role和rolebinding是名称空间级别内的许可权限。

基于角色的访问控制,用户作为访问的独立账号,角色(role)是授权机制:授权和许可(permission)

user扮演了角色1就拥有了角色1的权限,所有的授权都添加在角色上,用户扮演的 角色就拥有了角色权限

权限:对于对象,每一个被访问的组件都是对象,在restful 的api当中一切届对象,k8s上运行的组件分为三类, 对象占用了绝大部分,对象列表API,非对象资源,URL。在restful风格中的操作都是指在某个对象施加的(action)某种行为,称之operations。在一个对象上施加过程组合起来称为permissions. 而后可以在role上,授权于role拥有某个许可的权限(permissions)(在某些对象上实现某些操作的权限)。

如果需要使用基于角色访问控制,应该有user,role,permissions,而permissions就需要事先有一些objects,这些objects支持一些operations,这组合在一起就定义成了permissions。授于role,就完成了授权。

能够扮演角色并施加权限的有两个账号,如下:

userAccount和serviceAccount,serviceAccount,这些restful 接口执行类似与GET,PUT等操作,操作对象于位于url路径的对象列表或者一个具体的URL对象。把图一和图二绑定起来permissions,而后授予到角色上,让用户扮演角色,最后完成授权。

除开role和rol ebinding之外,还有两个组件clusterrole,clusetrrolebinding

在名称空间A中定义了角色(role),角色和user1建立绑定关系(rolebinding),user1就有了定义的角色(role)权限。user1的这些权限只能在当前名称空间下的所有pod生效。如下:

如果此时user1用户定义的是clusterRole,操作对象还是pod。user1用户和clusterRole建立绑定关系(也就是clusterRoleBinding),那就会突破名称空间的边界,而是集群级别的权限,生效的范围在整个集群。如下:

那么如果名称空间b中的user1的rolebingding绑定集群级别的ClusterRole(角色),而不是绑定namespace中的role(角色),即便如此。权限仍然在namespace中,因为user使用rolebinding绑定的clusterRole,对用户来讲权限就限制在namespace中。这样以来clusterrole权限降级到rolebinding所有权限。如果要对某一个或几个名称空间做用户权限则可以如此。如下:

  • role定义的在那个名称空间,生效范围在那个名称空间
0 分享

您可以选择一种方式赞助本站

支付宝扫码赞助

支付宝扫码赞助

日期: 2018-11-11分类: kubernetes

标签: kubernetes

发表评论