持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第21天，点击查看活动详情

前言

上一篇文章中我们创建了⼀个只能访问 kube-system 这个命名空间的ServiceAccount，本篇文章我们就来演示创建⼀个可以访问所有 namespace 的ServiceAccount对象，也是RBAC 的配置⽅法演示的最后一篇。

新建 ServiceAcount 对象

如果我们现在创建⼀个新的 ServiceAccount，需要他操作的权限作⽤于所有的 namespace，这个时候我们就需要使⽤到ClusterRole 和 ClusterRoleBinding 这两种资源对象了。同样，⾸先新建⼀个 ServiceAcount 对象：(haimaxy-sa2.yaml)

apiVersion: v1
kind: ServiceAccount
metadata:
name: haimaxy-sa2
namespace: kube-system

创建：

$ kubectl create -f haimaxy-sa2.yaml

创建 ClusterRoleBinding 对象

然后创建⼀个 ClusterRoleBinding 对象(haimaxy-clusterolebinding.yaml):

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

从上⾯我们可以看到我们没有为这个资源对象声明 namespace，因为这是⼀个 ClusterRoleBinding 资源对象，是作⽤于整个集群的，我们也没有单独新建⼀个 ClusterRole 对象，⽽是使⽤的 clusteradmin 这个对象，这是 Kubernetes 集群内置的 ClusterRole 对象，我们可以使⽤ kubectl getclusterrole 和 kubectl get clusterrolebinding 查看系统内置的⼀些集群⻆⾊和集群⻆⾊绑定，这⾥我们使⽤的 cluster-admin 这个集群⻆⾊是拥有最⾼权限的集群⻆⾊，所以⼀般需要谨慎使⽤该集群⻆⾊。

验证 ServiceAccount

创建上⾯集群⻆⾊绑定资源对象，创建完成后同样使⽤ ServiceAccount 对应的 token 去登录Dashboard 验证下：

$ kubectl create -f haimaxy-clusterolebinding.yaml
$ kubectl get secret -n kube-system |grep haimay-sa2haimay-sa2-token-nxgqx kubernetes.io/service-account-token 3 47m
$ kubectl get secret haimay-sa2-token-nxgqx -o jsonpath={.data.token} -n kube-system |base64 -d
# 会⽣成⼀串很⻓的base64后的字符串

结语

在 RBAC 中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限 。这就极大地简化了权限的管理。这样管理都是层级相互依赖的，权限赋予给角色，而把角色又赋予用户，这样的权限设计很清楚，管理起来很方便。

RBAC 认为授权实际上是Who 、What 、How 三元组之间的关系，也就是Who 对What 进行How 的操作，也就是“主体”对“客体”的操作。

我们在最开始接触到 RBAC 认证的时候，可能不太熟悉，特别是不知道应该怎么去编写 rules 规则，⼤家可以去分析系统⾃带的 clusterrole、clusterrolebinding 这些资源对象的编写⽅法，怎么分析？还是利⽤ kubectl 的 get、describe、 -o yaml 这些操作，所以 kubectl 最基本的⽤户⼀定要掌握好。

RBAC 只是 Kubernetes 中安全认证的⼀种⽅式，当然也是现在最重要的⼀种⽅式，后⾯我们再和⼤家⼀起聊⼀聊 Kubernetes 中的安全设计。