Kubernetes中有很多种内置的编排对象,此外还可以自定义API资源类型和控制器的编写方式.那么,我能不能自己写一个编排对象呢?答案是肯定的.而这,也正是Kubernetes项目最具吸引力的地方.
毕竟在互联网级别的大规模集群里,Kubernetes内置的编排对象,很难做到完全满足所有需求,所以很多实际的容器化工作,都会要求设计一个自己的编排对象,实现自己的控制器模式.
所以,我们可以基于插件机制来完成这些工作,而不需要修改任何一行代码.但是,如果要通过外部插件,在Kubernetes中实现新增和操作API对象,那么就必须先了解一个非常重要的知识:RBAC.
什么是RBAC呢?我们知道,Kubernetes中所有的API对象,都保存在Etcd里,但是呢,对这些API对象的操作,却一定都是通过访问kube-apiserver来实现的.其中一个非常重要的原因,就是你需要APIServer来帮助你做授权工作.而在Kubernetes项目中,负责完成授权(Authorization)工作的机制,就是RABC:基于角色的访问控制(Role-Based Access Control).
- Role:角色.它其实是一组规则,定义了一组对Kubernetes API对象的操作权限
- Subject:被作用者.既可以是"人",也可以是"机器",也可以是你在Kubernetes里定义的"用户"
- RoleBinding:定义了"被作用者"和"角色"的绑定关系.
| Role |
Role本身就是一个Kubernetes的API对象,定义如下所示:
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: mynamespace
name: example-role
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
如果对这个格式比较熟悉的话,应该能够一眼看出来:首先,这个Role对象指定了它能产生作用的Namespace是:mynamespace.
Namespace是Kubernetes项目里的一个逻辑管理单位,不同Namespace的API对象,在通过kubectl命令进行操作的时候,是互相隔离开的.这只是逻辑上的"隔离".Namespace并不会提供任何实际的隔离或者多租户能力.
Role对象的rules字段,就是它所定义的权限规则.在这里规则的意思就是:允许"被作用者",对mynamespace下面的Pod对象,进行GET,WATCH和LIST操作.
那么,这个具体的"被作用者"又是如何指定的呢?这就需要通过RoleBinding来实现了.
| Subject与RoleBinding |
RoleBinding本身也是Kubernetes的API对象.定义如下:
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: example-rolebinding
namespace: mynamespace
subjects:
- kind: User
name: example-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: example-role
apiGroup: rbac.authorization.k8s.io
由上,我们能够看到,这个RoleBinding对象里定义了一个subjects字段,即"被作用者".它的类型是User,即Kubernetes中的用户,这个用户的名字是example-user.但是,在Kubernetes中,并没有一个叫做"User"的API对象,这个User到底是从哪儿来的呢?
实际上,Kubernetes中的"User"就是"用户",只是一个授权系统里的逻辑概念.它需要通过外部认证服务来提供,或者也可以直接给APIServer指定一个用户名,密码文件.那么Kubernetes的授权系统,就可以从这个文件里找到对应的"用户".其实在大多数私有的使用环境中,只要使用Kubernetes提供的内置"用户",就足够了.
好像有点儿扯远了.这个等下再详细说吧.
再往下看,能够看到roleRef字段.正是通过这个字段,RoleBinding对象就可以直接通过名字,来引用我们前面定义的Role对象(example-role),从而定义了"被作用者(Subject)"和"角色(Role)"之间的绑定关系.
在这里需要强调一下:Role和RoleBinding对象都是Namespaced对象,它们对权限的限制规则仅在它们自己的Namespace内有效,roleRef也只能引用当前Namespace中的Role对象.
那么,对于非Namespaced(Non-namespaced)对象(比如:Node),或者某一个Role想要作用于所有的Namespace时,我们又该怎么去做授权呢?
这时,就必须要使用ClusterRole和ClusterRoleBinding这两个组合了.这两个API对象的用法和Role与RoleBinding完全一样,只不过它们的定义里,没有了Namespace字段.
具体如下所示:
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: example-clusterrole
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: example-clusterrolebinding
subjects:
- kind: User
name: example-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: example-clusterrole
apiGroup: rbac.authorization.k8s.io
上面的例子中,意味着名叫example-user用户,拥有对所有Namespace里的Pod进行GET,WATCH和LIST操作的权限.更进一步的说,在Role或者ClusterRole里面,如果要赋予用户example-user所有权限,那么就可以给它指定一个verbs字段的全集,如下所示:
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
当然,也可以根据自己的需求,只针对某一个具体的对象进行权限设置.比如:
rules:
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["my-config"]
verbs: ["get"]
这个例子就表示,这条规则的"被作用者",只对名叫"my-config"的ConfigMap对象,有进行GET操作权限.
在上面提了一下,大多数时候,我们其实都不太使用"用户"这个功能,而是直接使用Kubernetes中的"内置用户",而这个"内置用户"就是:ServiceAccount.
| ServiceAccount分配权限的过程 |
通过一个实例,来讲解一下为ServiceAccount分配权限的过程.
首先,需要定义一个ServiceAccount.它的API对象非常简单,如下所示:
apiVersion: v1
kind: ServiceAccount
metadata:
namespace: mynamespace
name: example-sa
可以看到,一个最简单的ServiceAccount对象,只需要Name和Namespace这两个最基本的字段.
然后我们通过编写RoleBinding的YAML文件,来为这个ServiceAccount分配权限:
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: example-rolebinding
namespace: mynamespace
subjects:
- kind: ServiceAccount
name: example-sa
namespace: mynamespace
roleRef:
kind: Role
name: example-role
apiGroup: rbac.authorization.k8s.io
接下来,我们用kubectl命令创建这三个对象:
$ kubectl create -f svc-account.yaml
$ kubectl create -f role-binding.yaml
$ kubectl create -f role.yaml
然后,来查看一下ServiceAccount的详细信息:
$ kubectl get sa -n mynamespace -o yaml
- apiVersion: v1
kind: ServiceAccount
metadata:
creationTimestamp: 2018-09-08T12:59:17Z
name: example-sa
namespace: mynamespace
resourceVersion: "409327"
...
secrets:
- name: example-sa-token-vmfg6
可以看到,Kubernetes会为一个ServiceAccount自动创建并分配一个Secret对象.这个Secret就是这个ServiceAccount对应的,用来和APIServer进行交互的授权文件,一般称它为:Token.
Token文件的内容一般是证书或者密码,它以一个Secret对象的方式,保存在Etcd当中.
此时,用户的Pod就可以声明使用这个ServiceAccount了.
| 对以上内容的总结 |
上面内容有些多,最后来一个总结:
所谓角色(Role),其实就是一组权限规则列表.分配这些权限的方式,就是通过创建RoleBinding对象,将被作用者(Subject)和权限列表进行绑定.
另外,与之对应的ClusterRole和ClusterRoleBinding,则是Kubernetes集群级别的Role和RoleBinding,它们的作用范围不受Namespace限制.
尽管权限的被作用者可以用很多种(比如,User,Group等),但在我们平常的使用中,最普遍的用法还是ServiceAccount.所以,Role+RoleBinding+ServiceAccount的权限分配方式,是最应该掌握的内容.
以上内容来自我学习<深入剖析Kubernetes>专栏文章之后的一些见解,有偏颇之处,还望指出.
感谢您的阅读~