回复
kubernete编排技术六：RBAC权限控制
gq_design
发布于 2022-5-1 09:01
6855浏览
0收藏
作者 | 朱晋君
来源 | 君哥聊技术（ID：gh_1f109b82d301）
这是kubernete编排技术的第六篇，本文主要讲一下RBAC。之前讲过，kubernete所有API对象，都保存在etcd里。要访问和操作这些对象，一定会通过apiserver，因为apiserver可以做授权工作。
kubernete发展至今，授权模式一共有如下6种，其中RBAC这种授权模式从1.8开始已经成了稳定功能，只要设置通过设置–authorization-mode=RBAC就可以启用。
- 基于属性的访问控制ABAC
- 基于角色的访问控制RBAC
- Webhook
- Node
- 总是拒绝AlwaysDeny
- 总是允许AlwaysAllow
作为业务开发者，我们多多少少也接触过授权，比如spring security，sso等。其实RBAC的授权很类似，它有3个角色相关定义：Role(角色)、Subject(主体或被作用者)和RoleBinding(绑定)，还有2个规则：资源、操作类型。
所以在RBAC中，需要api授权的时候，首先需要定义Role，然后需要定义Role和subject绑定关系RoleBinding，定义角色的时候需要指定该角色可以访问的资源和操作类型。
定义Role和ClusterRole
Role首先是一个api对象，在kubernete中有2种，Role和ClusterRole，很明显这2个就是普通角色和集群角色。定义的时候只要把yaml中的kind指定为Role就可以了。下面我们定义了一个名字叫test-role的Role，这个Role可以对namespace是mynamespace的pod进行get、watch和list操作。
下面我们再定义一个名字叫secret-reader的ClusterRole，需要注意集群角色是没有namespace的(因为集群角色不需要namespace进行逻辑隔离)，这里定义的资源类型是secrets，secrets也是一种api对象，后面再讲，操作类型跟上面的Role一样。
注意：
1.如果我们要给当前角色赋予所有权限，可以定义verbs如下：
2.这儿也可以针对具体的对象进行设置，比如下面就是只能对name是my-config的configmaps资源进行get操作。
3.kubernete提供了四个预先定义好的ClusterRole供用户使用：cluster-admin(集群中所有操作)、admin(单节点所有操作)、edit(读写操作)、view(只读操作)。
需要提一下的是，cluster-admin对应的是整个集群中的最高权限(verbs=*)。下面的命令可以看出每个角色的权限列表：
角色的绑定RoleBinding
RoleBinding也是一个api对象，所以定义的时候只要申明kind是RoleBinding就可以了。下面这个RoleBinding名字叫test-rolebinding，定义了一个subjects即被作用对象，是一个叫jinjunzhu的用户。简而言之，就是jinjunzhu这个用户绑定了test-role这个角色，从而绑定了资源的get、watch和list操作。
RoleBinding也可以绑定集群角色角色，这个绑定只能在mynamespace中生效，绑定的正是我们前面定义的名字叫做secret-reader的ClusterRole，这样管理员可以在集群中复制这个公共角色，然后在命名空间中进行复用。yaml文件代码如下：
下面再看一个ClusterRoleBinding，这儿定义的被作用者subject是一个名字叫做jinjunzhu的Group，绑定关系是名字叫做secret-reader，这个绑定允许jinjunzhu这个组中的所有用户对集群中任何namespace中的secrets进行get、watch和list操作。
注意：这个绑定关系是没有namespace定义的。
主体或被作用者subject
在上面的subjects定义中，使用到了User和Group。
首先我们介绍一下User，它实际上是一个为了授权的逻辑概念。一般情况下，kubernete集群为我们提供的内置用户就能满足我们使用了，我们也可以通过外部认证服务比如keystone或者直接给APIServer指定用户名密码文件来指定。
如下是名字是jinjunzhu的用户：
而Group只是一组User，这一组用户也可以由外服授权服务来提供。
下面这个定义是用户名为jinjunzhu的Group：
注意：
ServiceAccount中Users，在kubernete里对应的name是：
ServiceAccount中Group，在kubernete里对应的name是：
下面这个定义是所有的用户：
下面的定义是所有内置用户：
下面的定义是所有namespace是jinjunzhu的所有内置用户：
关于如何使用外部授权服务，这里就不再详细介绍了。
进行试验
上面我们提到过，一般情况下，kubernete为我们提供的内置用户就能满足我们使用了，这个内置用户或者用户组就是ServiceAccount。
首先我定义一个name是jinjunzhu的ServiceAccount，serviceaccount.yaml文件内容如下：
接着我们定义一个Role，Role.yaml文件内容如下：
然后我们定义RoleBinding，RoleBinding.yaml文件内容如下：
因为上面用到了mynamespace，我们需要创建这个namespace, mynamespaces.yaml文件内容如下：
下面我们创建这4个api对象，命令如下：
创建成功后，首先我们看一下ServiceAccount，kubernete为它分配了简写sa，查看时可以使用：
从上面的输出可以看到，kubernete为jinjunzhu这个ServiceAccount分配了一个secrets，这个名字叫jinjunzhu-token-qxttq的secrets，它就是用来跟apiserver进行交互的token信息，只不过是以secrets对象的格式信息保存在etcd当中。
然后，我们从下面的输出可以看出，Role和RoleBinding已经创建成功了。
这时我们定义一个pod，这个pod名字叫sa-pod，镜像是我之前使用的一个springboot镜像，我们定义这个pod使用我们刚刚创建的名字叫jinjunzhu的ServiceAccount，
这个文件我们命名为sa-pod.yaml,然后创建这个pod，命令如下：
创建成功后，我们用describe看一下这个pod的详情：
上面输出的Mounts部分信息我们可以看到，前面我们创建jinjunzhu这个ServiceAccount时生成的token已经挂载到了一个目录下面，这是我们进入这个容器内部，如下所示：
可以看到容器里面已经有了一个ca.crt文件，容器里的应用就是用这个文件来访问apiserver的。根据前面Role定义，这个ServiceAccount的操作权限只有get、watch和list。
最后要说的是，如果我们声明pod的时候，没有定义serviceAccountName，kubernete会怎么控制pod的操作权限呢?
还是上面的sa-pod.yaml,我们删除serviceAccountName，重新创建pod，然后用describe看一下详情，下面是我截取了部分输出：
可以看到，kubernete会为这个pod创建一个名字叫default的ServiceAccount，然后为它绑定一个特殊的Secret，我们看一下详情：
注意：default的ServiceAccount拥有的访问apiserver的权限比较多，所以我们一般应该声明一个ServiceAccount进行绑定，用来对操作权限进行控制。
总结
kubernete基于角色的访问控制，其实是通过Role和RoleBinding来实现的，角色中定义了操作权限，然后跟User进行绑定，这个User一般可以用ServiceAccount对象。跟集群相关的访问控制还有ClusterRole和ClusterRoleBinding，这2个对象是集群范围的，不受namespace的限制。
分类
赞
收藏
回复
相关推荐
