RBAC在k8s中的应用

ServiceAccount

首先需要了解ServiceAccount。ServiceAccount顾名思义就是账户，pod使用这个账户和API服务器进行交互，API服务器能对这个账户进行认证（确定你是谁），然后对这个账户进行授权（你能干些什么）。

每个命名空间都有默认的ServiceAccount。在创建pod时，如果没有明确指定ServiceAccount将会使用默认的serviceAccount。若要创建一个ServiceAccount，可以使用如下的命令

kubectl create serviceaccount foo

ServiceAccount会关联一个Secret，可以通过

kubectl describe sa 

查看Secret的名称。这个Secret包含3部分内容

ca.crt
namespace
token

ca.crt用于认证API服务器，token用于让API服务器认证自己。最终这个Secret会被挂载到
/var/run/secrets/kubernetes.io/serviceaccount目录下。

通过在pod定义文件中的spec.serviceAccountName字段上设置ServiceAccount的名称来为pod指定ServiceAccount。

RBAC-基于角色的权限控制

RBAC权限模型是一个比较常见的权限模型，主要包括以下一些概念

1. 资源。资源上可以执行一些动作，也是作为权限的载体。
2. 动作。在资源上执行的一组操作。
3. 角色。一个角色对应了一组操作资源的权限。
4. 用户。真正想要一组权限的实体，一般将用户绑定到角色上，那这个用户就拥有了这个角色绑定的权限。
5. 角色绑定。将用户绑定到角色。

在k8s中，资源包括pod, replicaSet, deployment等对象。ServiceAccount对应上面提到的用户。动作如创建资源，修改资源，删除资源等。k8s中的动词和HTTP方法之间的映射关系如下

HTTP方法	单一资源的动词	集合的动词
GET、HEAD	get(以及watch用于监听)	list(以及watch)
POST	create	n/a
PUT	update	n/a
PATCH	patch	n/a
DELETE	delete	deletecollection

此外，k8s还有以下一些资源，是和角色、角色绑定相关的。包括

1. Role和ClusterRole。它们指定了在资源上可以执行哪些动词。Role是命名空间下的，ClusterRole是集群范围内的
2. RoleBinding和ClusterRoleBinding。将上述角色绑定到特定的用户、组或ServiceAccount上。RoleBinding是命名空间下的，ClusterRoleBinding是集群范围内的

Role的yaml文件如下所示

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: foo
  name: role-test
rules:
- apiGroups: [""]
   verbs: ["get", "list"]
  resources: ["services"]

RoleBinding的yaml文件如下所示

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: foo
  name: test-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: role-test
subjects:
- kind: ServiceAccount
  name: default
  namespace: foo

可以通过如下命令将ServiceAccount和角色绑定(创建rolebinding)

kubectl create rolebinding test --role=role-test --serviceaccount=foo:default -n foo

如果要绑定一个角色到一个user(用户)而不是ServiceAccount，使用--user作为参数制定用户名，绑定角色到组，可以使用--group参数

关于role, clusterRole, roleBinding, clusterRoleBinding有以下一些注意点

1. clusterRole是一种集群级别资源，它允许访问没有命名空间的资源和非资源型的url，或者作为单个命名空间内部绑定的公共角色，从而避免重新定义相同的角色，也可以做到跨命名空间访问资源
2. roleBinding是在命名空间下的，但它们也可以引用clusterRole。但是这个clusterRole只能绑定命名空间下的资源，通过这种方式，可以定义一些公共的角色，避免每个命名空间下都定义一个相同的角色
3. 但是对于集群级别的资源或者非资源型的URL，只能通过clusterRoleBinding和clusterRole进行绑定。
4. ServiceAccount可以和本命名空间下的roleBinding绑定，也可以和其他命名空间下的roleBinding绑定，也可以和clusterRoleBinding绑定。ServiceAccount可以获得对应角色的权限

访问的资源	使用的角色类型	使用的绑定类型
集群级别的资源	ClusterRole	ClusterRoleBinding
非资源型URL	ClusterRole	ClusterRoleBinding
在任何命名空间中的资源（和跨所有命名空间的资源）	ClusterRole	ClusterRoleBinding
在具体命名空间中的资源（在多个命名空间中重用这个相同的ClusterRole）	ClusterRole	RoleBinding
在具体命名空间中的资源（Role必须在每个命名空间中定义好）	Role	RoleBinding

通过以下命令可以查看默认的集群角色和绑定

kubectl get clusterrolebindings
kubectl get clusterroles