首页 » 运维 » 正文

Kubernetes 的RBAC

RBAC 的全称是Role-Based Access Control , 这套机制是Kubernetes中专门负责授权的,例如某个“用户” 可以操作哪些资源

首先我们要明确两个概念:

1, ROLE : 其实原理上是一组规则,定了了一些操作,例如,get pod , get deployment, delete pod ,但是这个地方并没有定义谁,也就是说谁和我这个Role 绑定了,谁就拥有了我这个ROLE里边定义的操作权限

2,RoleBinding: 记录了ROLE和谁绑定 了(“用户”,“组”,serviceaccount,node…)

Kubernetes 中并没有User 和 Group的 , 它在kubernetes中只是一个逻辑概念,具体的用户是用外部第三方提供的,例如github ,aws

我们看一个Role例子:

这个Role的就是定义了说,谁挂载了我这个ROle 就可以对Pods 这个对象进行三个操作: get watch list

我们创建完Role之后就可以创建rolebinding了

这个rolebindings的意思就是说,在mynamespace下,User : example-user 绑定了example-role 这个普通role,拥有了这个role里边所有的权限(从上边的例子我们知道这个用户能对Pods 对象进行 get watch list)

普通的role 和 rolebindings是对某个namespace 起作用的,有时候我们可能想所有的namespace都生效,肯定不可能每个namespace去创建,这个时候,kubernetes提供给我们了两个全局的概念:

ClusterRole 和 ClusterRoleBinding 用法一模一样,只不过没有了namespace :

 

这里我们说一下serviceaccount 的概念,serviceaccount相当于系统用户:

创建非常简单:

然后我们可以通过rolebinds 给这个serviceaccount 权限

当我们创建完serviceaccount以后,系统会自动创建一个secret对象,这个就是Token,也就是Serviceaccount用这个secret里边的令牌和kubernetes api进行交互

这个时候,我们创建pod的时候就可以使用serviceaccount了

启动后,我们容器里边的应用,就可以使用我们serviceaccount的token(会自动挂载进去)来和api进行交互,可以做GET、WATCH 和 LIST

默认情况下,你的Pod会自动挂载namespace下的default serviceaccount

Zhiming Zhang

Senior devops at Appannie
一个奔跑在运维路上的胖子
Zhiming Zhang

发表评论