Kubernetes(k8s)-RBAC服务账户(ServiceAccount)介绍&应用

作者介绍：简历上没有一个精通的运维工程师。请点击上方的蓝色《运维小路》关注我，下面的思维导图也是预计更新的内容和当前进度(不定时更新)。

我们上一章介绍了Docker基本情况，目前在规模较大的容器集群基本都是Kubernetes，但是Kubernetes涉及的东西和概念确实是太多了，而且随着版本迭代功能在还增加，笔者有些功能也确实没用过，所以只能按照我自己的理解来讲解。

RBAC（基于角色的访问控制，Role-Based Access Control）是一种用于管理和控制对系统资源的访问的方法。在 Kubernetes 中，RBAC 提供了一种声明式的方法来配置访问策略，允许管理员通过角色和角色绑定来精细控制用户（包括用户和 service accounts）以及它们对 Kubernetes API 的访问权限。

角色分类

Kubernetes管理的ServiceAccount(服务账户，简称sa)和UserAccount（用户账户）。

用户账户(UserAccount)

超级管理员，自定义管理员都属于此类，属于集群外部访问集群。kubeadm在部署的时候会自动给我们创建一个超级管理员，并自动配置对应的账号和权限，包括需要的证书，也就是/etc/kubernetes/admin.conf这个文件，然后这个文件在部署完成以后会放置到/root/.kube/config,供kubeclt命令使用。

服务账户(ServiceAccount)

一般用于集群内部访问kube-apiservice，其实主要就是pod访问集群，比如监控（Prometheus），webui（Dashboard）。他们本质还是是一个个Pod容器，而Pod容器访问集群一样是需要认证和授权。系统会为每个命名空间创建一个默认的default的ServiceAccount，这个ServiceAccount会自动关联到一个Secret，通过Sceret提供的token信息连接到kube-apisever，获取对应的信息。这个ServiceAccount具有kubernetes最低权限。

默认创建的每一个pod，都会挂载当前命名空间的ServiceAccount，然后如果当Pod内部有调用apiserver的需求就会来这里获取认证信息。

Mounts:        /var/run/secrets/kubernetes.io/serviceaccount from default-token-7nb6z (ro)

案例

创建ServiceAccount

创建一个名字为：examples-sa的ServiceAccount，由于没有绑定任何其他资源，所以他和默认的default权限是一样的。​​​​​​​

#创建sa的yaml文件
apiVersion: v1
kind: ServiceAccount
metadata:
  name: example-sa
  namespace: dev

默认的SA只能满足Kubernetes的基本运行，如果我们要给我们自己的服务账户添加对应的权限，则必须要先理解下面的概念。

简单来说就是选择对应版本就代表了你可以选择什么对应的资源，不同的资源在不同的版本里面；不同的resources则代表你可以操作的对应的资源；不同verbs则代表对资源的具体权限。

apiGroup:
  - "描述": "支持的API组列表，例如："
  - "核心API组": "空字符串表示核心API群"
  - "示例": 
    - "APIVersion: batch/v1"
    - "APIVersion: extensions/v1beta1"
    - "APIVersion: apps/v1"

resources:
  - "描述": "支持的资源对象列表，例如："
  - "示例": 
    - "pods"
    - "deployments"
    - "jobs"

verbs:
  - "描述": "对资源对象的操作方法列表，例如："
  - "示例": 
    - "get"
    - "watch"
    - "list"
    - "delete"
    - "replace"
    - "patch"

​​​​​​

Role

一个名叫dev-role的角色，作用范围dev的namespace，权限范围是pod，能执行的动作包括：get，watch，list。​​​​​​​

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: dev
  name: dev-role
rules:
- apiGroups:
  - ""
  resources:
  - "pods"
  verbs:
  - "get"
  - "watch"
  - "list"

RoleBinding

一个名叫dev-rolebinding的角色绑定，作为范围是dev命令空间，绑定给了example-sa这个ServiceAccount，使这个ServiceAccount具有了刚刚我们在角色里面定义的权限，这样我们就实现ServiceAccount，Role，和RoleBinding闭环。

Role提供对应的权限，RoleBinding把这个权限绑定到了服务账服ServiceAccount,这样只要使用ServiceAccount这个服务账号就具有定义好的权限。​​​​​​​

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dev-rolebinding
  namespace: dev
subjects:
- kind: ServiceAccount
  name: example-sa
roleRef:
  kind: Role
  name: dev-role
  apiGroup: rbac.authorization.k8s.io

上面的操作的只能局限于某一个特定的命名空间(NameSpace),如果要全局生效则需要采用:ClusterRole和ClusterRoleBinding。

ClusterRole

一个名叫secret-reader的集群角色，作用范围是所有NameSpace，权限范围是Secrets，能执行的动作包括：get，watch，list。​​​​​​​

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

ClusterRoleBinding

ClusterRoleBinding 将名为 manager-sa 的服务账户（位于 test 命名空间中）绑定到 secret-reader 集群角色。这意味着 manager-sa 服务账户将具有在集群范围内读取所有 Secrets的权限。​​​​​​​

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global-manager-sa
subjects:
- kind: ServiceAccount
  name: manager-sa
  namespace: test
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

apiVersion: v1
kind: ServiceAccount
metadata:
  name: manager-sa
  namespace:test

​​​​​​​

虽然我们的ServiceAccount和ClusterRoleBinding都带有命名空间，实际上我们引用的该ServiceAccount的Pod也是具有命名空间属性的。所以它这里并没有问题。

这里介绍的RBAC广泛用于各种运行在Kubernetes集群内部的一些服务，包括我们前面讲过的NFS及后面会讲的很多资源都会用到这个配置，因为他们需要通过这个配置来定义自己的权限。

运维小路

一个不会开发的运维！一个要学开发的运维！一个学不会开发的运维！欢迎大家骚扰的运维！

关注微信公众号《运维小路》获取更多内容。