普通用户没有crontab权限_kubernetes基于自定义用户的权限分配机制

原创：80后程序员的世界观(微信公众号ID：zhuangmeilicom)，欢迎分享，转载请保留出处。

本文分两个部分：

1. kubernetes 集群架构图
2. kubernetes 集群基于用户的认证与权限分配机制

一、kubernetes 集群架构图

k8s集群由master节点和node节点组成。

master节点一般为一个，如果做高可用，可以扩展为三个。master节点运行etcd，API Server， Controller Manager 和 Scheduler 这四个组件；

node节点有多个(一个以上)，node节点主要负责运行容器；

k8s集群架构图

k8s集群通过API Server提供了rest api接口。集群的运维和使用都是通过rest api接口来进行的。运维和使用k8s集群有两种方式(其实是一种，因为最终都会下沉到rest api方式)：

1. 通过kubectl工具
2. 直接调用api server的rest api来进行操作

那么问题来了，无论是通过kubectl或者http rest api来访问，为了集群的安全，就需要有一套认证和鉴权的机制。一般在设计中，我们会通过用户名来做权限的隔离。那接下来我们来讲讲k8s集群如何基于user进行认证和权限分配。

二、kubernetes 集群基于user的认证与权限分配

认证和权限是不同的。认证表示准许进入；而权限表示具体的权限。比如每个人都可以通过门禁卡进入，表明是公司的员工，这就是认证通过；但是员工之中有经理、有普通与员工，在公司的权力也是不同的，这就是权限。k8s也是类似的机制，通过认证+权限的机制，保证集群的安全、保证不同的用户对集群有不同的权限。

1.先来看认证：

每个k8s集群都有一个集群根证书，位置在每个pod的的/var/run/secrets/kubernetes.io/serviceaccount/ca.crt文件。你可以通过这个根证书给user颁发证书，大概思路如下：

(1)创建CSR

cat <

注意：这里的CN对应的就是认证对象，我们在这里填写username

(2)通过k8s api-server 创建一个csr object

(3)管理员批准或者拒绝此CSR

(4)下载证书并使用

通过kubectl config命令将该证书注入到kubeconfig file，客户端就可以通过kubeconfig文件来访问k8s集群了。这样客户端所代表的user就是上述CSR文件里CN字段指定的username，这里就是testuser。

那么这个用户在集群里是什么权限呢？这就需要了解k8s的权限机制(RBAC)了

2.再来看权限

集群内部的权限是由rolebinding来指定的。rolebinding其实是个中间产物，用于做对象和权限的解耦。k8s里通过role或者clusterrole来定义具体的权限；通过普通用户或者serviceaccount来定义权限的主体；而给主体分配什么权限则是由rolebinding来实现的。详情大家可以参考k8s相关的文档。由于我们这里讨论的是普通用户，所以你的rolebinding可能是这样子的：

kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1beta1metadata:  name: read-pods  namespace: defaultsubjects:- kind: User  name: testuser apiGroup: rbac.authorization.k8s.ioroleRef:  kind: Role  name: pod-reader  apiGroup: rbac.authorization.k8s.io

上述示例代码允许用户testuser从default namespace中读取pod。

按照上面的方法，你也可以创建一个user2,并让user2在集群范围内有cluster admin权限。

以上我只是讲了大概的思路，考虑到手机端看代码体验不太好，所以没有贴出具体的步骤。大家如有疑问，可以在下方评论区评论。

作者简介：研华科技软件主管，聚焦linux内核技术和k8s云平台架构设计。我会在这里分享kubernetes云平台的架构设计。也会分享我们针对某些开源组件的优劣评估和性能测试以及优化过程。欢迎大家一起探讨云原生技术。