ServiceAccount
首先需要了解ServiceAccount。ServiceAccount顾名思义就是账户，pod使用这个账户和API服务器进行交互，API服务器能对这个账户进行认证（确定你是谁），然后对这个账户进行授权（你能干些什么）。
每个命名空间都有默认的ServiceAccount。在创建pod时，如果没有明确指定ServiceAccount将会使用默认的serviceAccount。若要创建一个ServiceAccount，可以使用如下的命令
kubectl create serviceaccount fooServiceAccount会关联一个Secret，可以通过
kubectl describe sa <ServiceAccount name>查看Secret的名称。这个Secret包含3部分内容
ca.crt
namespace
tokenca.crt用于认证API服务器，token用于让API服务器认证自己。最终这个Secret会被挂载到
/var/run/secrets/kubernetes.io/serviceaccount目录下。
通过在pod定义文件中的spec.serviceAccountName字段上设置ServiceAccount的名称来为pod指定ServiceAccount。
RBAC-基于角色的权限控制
RBAC权限模型是一个比较常见的权限模型，主要包括以下一些概念
- 资源。资源上可以执行一些动作，也是作为权限的载体。
- 动作。在资源上执行的一组操作。
- 角色。一个角色对应了一组操作资源的权限。
- 用户。真正想要一组权限的实体，一般将用户绑定到角色上，那这个用户就拥有了这个角色绑定的权限。
- 角色绑定。将用户绑定到角色。
在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还有以下一些资源，是和角色、角色绑定相关的。包括
- Role和ClusterRole。它们指定了在资源上可以执行哪些动词。Role是命名空间下的，ClusterRole是集群范围内的
- 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有以下一些注意点
- clusterRole是一种集群级别资源，它允许访问没有命名空间的资源和非资源型的url，或者作为单个命名空间内部绑定的公共角色，从而避免重新定义相同的角色，也可以做到跨命名空间访问资源
- roleBinding是在命名空间下的，但它们也可以引用clusterRole。但是这个clusterRole只能绑定命名空间下的资源，通过这种方式，可以定义一些公共的角色，避免每个命名空间下都定义一个相同的角色
- 但是对于集群级别的资源或者非资源型的URL，只能通过clusterRoleBinding和clusterRole进行绑定。
- ServiceAccount可以和本命名空间下的roleBinding绑定，也可以和其他命名空间下的roleBinding绑定，也可以和clusterRoleBinding绑定。ServiceAccount可以获得对应角色的权限
访问的资源 | 使用的角色类型 | 使用的绑定类型 |
集群级别的资源 | ClusterRole | ClusterRoleBinding |
非资源型URL | ClusterRole | ClusterRoleBinding |
在任何命名空间中的资源（和跨所有命名空间的资源） | ClusterRole | ClusterRoleBinding |
在具体命名空间中的资源（在多个命名空间中重用这个相同的ClusterRole） | ClusterRole | RoleBinding |
在具体命名空间中的资源（Role必须在每个命名空间中定义好） | Role | RoleBinding |
通过以下命令可以查看默认的集群角色和绑定
kubectl get clusterrolebindings
kubectl get clusterroles
