前面我们的示例中,我们创建的ServiceAccount是与cluster-admin 绑定的,这个用户默认有最高的权限,实际生产环境中,往往需要对不同运维人员赋预不同的权限.而根据实际情况也可能会赋予开发人员只读的权限.这一节我们将介绍如何创建不同权限的用户.
在开始之前,我们先了解一些关于kubernetes RABA的一些基本概念.
Role
Role表示是一组规则权限，只能累加，Role可以定义在一个namespace中，只能用于授予对单个命名空间中的资源访问的权限。比如我们新建一个对默认命名空间中Pods具有访问权限的角色：
kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: namespace: default name: pod-reader rules: - apiGroups: [""] # "" indicates the core API group resources: ["pods"] verbs: ["get", "watch", "list"]ClusterRole
ClusterRole具有与Role相同的权限角色控制能力，不同的是ClusterRole是集群级别的，可以用于:
集群级别的资源控制(例如 node 访问权限)
非资源型 endpoints(例如 /healthz 访问)
所有命名空间资源控制(例如 pods)
比如我们要创建一个授权某个特定命名空间或全部命名空间(取决于绑定方式)访问secrets的集群角色：
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: # "namespace" omitted since ClusterRoles are not namespaced name: secret-reader rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"]RoleBinding和ClusterRoleBinding
RoloBinding可以将角色中定义的权限授予用户或用户组，RoleBinding包含一组权限列表(subjects)，权限列表中包含有不同形式的待授予权限资源类型(users、groups、service accounts)，RoleBinding适用于某个命名空间内授权，而 ClusterRoleBinding适用于集群范围内的授权。
比如我们将默认命名空间的pod-reader角色授予用户jane，这样以后该用户在默认命名空间中将具有pod-reader的权限：
# This role binding allows "jane" to read pods in the "default" namespace. kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: read-pods namespace: default subjects: - kind: User name: jane apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.ioRoleBinding同样可以引用ClusterRole来对当前 namespace 内用户、用户组或 ServiceAccount 进行授权，这种操作允许集群管理员在整个集群内定义一些通用的 ClusterRole，然后在不同的 namespace 中使用 RoleBinding 来引用
例如，以下 RoleBinding 引用了一个 ClusterRole，这个 ClusterRole 具有整个集群内对 secrets 的访问权限；但是其授权用户 dave 只能访问 development 空间中的 secrets(因为 RoleBinding 定义在 development 命名空间)
# This role binding allows "dave" to read secrets in the "development" namespace. kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: read-secrets namespace: development # This only grants permissions within the "development" namespace. subjects: - kind: User name: dave apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io使用 ClusterRoleBinding 可以对整个集群中的所有命名空间资源权限进行授权；以下 ClusterRoleBinding 示例展示了授权 manager 组内所有用户在全部命名空间中对 secrets 进行访问
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace. kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: read-secrets-global subjects: - kind: Group name: manager apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io 限制dashboard 用户权限有了上面的理论基础，我们就可以来新建一个用户，为该用户指定特定的访问权限了，比如我们要实现以下功能:
新增一个新的用户tyler(tyler.yml)
该用户只能对命名空间kube-system下面的pods和deployments进行管理
首先,我们先创建这个ServiceAccount
kubectl create sa tyler -n kube-system
然后我们新建一个角色role-tyler(role-tyler.yml)
kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: kube-system name: role-tyler rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"] - apiGroups: ["extensions", "apps"] resources: ["deployments"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]注意上面的rules规则：管理pods和deployments的权限。
然后我们创建一个角色绑定，将tyler用户绑定到role-tyler角色,这样用户就拥有了角色的权限.
执行命令创建文件
$ kubect create -f tyler.yml $ kubect create -f role-tyler.yml