RBAC权限模型

无论是直接使用kubectl还是具体Pod内的某个服务，对k8s中定义的资源进行操作实际上都需要通过API Server，那么这就涉及到鉴权。实际上，API Server采用RBAC权限模型进行授权管理，在实际开中有很多地方都需要我们配置权限，例如我们的程序要读取一下命名空间下的Service列表，此时我们访问API Server的资源就需要配置对应的权限。本篇笔记我们简述其中的重要概念和简单使用方法。

注意：如果你只是在k8s或基于k8s的公有云平台上部署自己的程序，那么只需要了解本篇中介绍的内容即可；如果你是集群运维人员或是基于k8s进行平台架构开发，则需要深入了解相关的技术细节，具体可以参考官方文档。

Account 账号

k8s中的账号分为两种：UserAccount和ServiceAccount。两者的区别是前者面向的是使用kubectl命令的运维人员，后者面向的是集群内的Pod，围绕这两种访问主体，两种Account的设计和使用方式也是完全不同的。

UserAccount

UserAccount用于运维人员通过kubectl客户端访问k8s集群。这里我们要知道的是k8s中不存在表示这类账号的对象。在第一节我们搭建k8s集群时，其中有一个操作写入了~/.kube/config配置文件。实际上，我们使用kubectl程序时，其认证等信息就存储在~/.kube/config配置文件内，我们可以观察其中的内容。

配置文件中，可以看到我们实际上使用的是一个名叫kubernetes-admin的用户，除此之外配置文件中还包含了API Server的地址和端口，以及和认证相关的Base64字符串等信息。

ServiceAccount

ServiceAccount用于Pod内的进程通过APIServer访问k8s集群。如果我们使用一些k8s的管理平台比如Dashboard程序，我们可以在界面中对k8s中的资源进行增删改查操作，这些操作都是管理程序的Pod调用API Server实现的，实际上这类程序就需要通过ServiceAccount账号来授权。如果你开发的程序不使用API Server，则完全不需要关心ServiceAccount。

下面例子我们在default命名空间下，创建了一个名为admin的ServiceAccount。

kind: ServiceAccount
apiVersion: v1
metadata:
  name: admin
  namespace: default

此外，在每个命名空间下都有一个名叫default的ServiceAccount，如果我们的Pod没有指定任何账号，则默认会挂到这个账号下，default默认没有任何权限。

Role 角色

k8s中角色分为两种：Role和ClusterRole。前者指定为一个命名空间内资源的访问权限，后者则是集群作用域内的资源。

角色指定了一组操作权限，一个用户如果指定了多个角色，则其权限会叠加。一个创建角色的例子如下。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" 标明 core API 组
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

RoleBinding 用户角色绑定

对应角色，角色绑定也分为两种：RoleBinding和ClusterRoleBinding。

第一节中，我们曾创建如下角色绑定。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: admin
  namespace: kube-system

上面例子将admin这个ServiceAccount和cluster-admin这个ClusterRole进行了绑定。

作者：Gacfox