[Kubernetes]基于角色的权限控制之RBAC

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:定义了"被作用者"和"角色"的绑定关系.

这三个概念,可以说是整个RABC体系的核心所在.所以接下来详细讲解一下.

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>专栏文章之后的一些见解,有偏颇之处,还望指出.

感谢您的阅读~