kubernetes实战篇之Dashboard的访问权限限制

　　前面咱们的示例中,咱们建立的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.io
　　
　　RoleBinding一样能够引用ClusterRole来对当前 namespace 内用户、用户组或 ServiceAccount 进行受权，这种操做容许集群管理员在整个集群内定义一些通用的 ClusterRole，而后在不一样的 namespace 中使用 RoleBinding 来引用
　　
　　例如，如下 RoleBinding 引用了一个 ClusterRole，这个 ClusterRole 具备整个集群内对 secrets 的访问权限；可是其受权用户 dave 只能访问 development 空间中的 secrets(由于 RoleBinding 定义在 development 命名空间)
　　
　　# This role binding allows www.huichengtxgw.com dave"www.wanhongzpt.com to read secrets in the "development" namespace.
　　
　　kind: RoleBinding
　　
　　apiVersion: rbac.authorization.k8s.io/v1beta1
　　
　　metadata:
　　
　　name: read-secrets
　　
　　namespace: development # This only www.baitengpt.com  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 www.yongshiyule178.com"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"www.xingtuyLgw.com]
　　
　　verbs: ["get",www.changjianyl.com "watch", "list"]
　　
　　- apiGroups: ["extensions", "apps"]
　　
　　resources: ["deployments"]
　　
　　verbs: ["get", "list"www.yifayule2d.com, "watch", "create", www.yifa5yl.com"update", "patch", "delete"]
　　
　　注意上面的rules规则：管理pods和deployments的权限。
　　
　　而后咱们建立一个角色绑定，将tyler用户绑定到role-tyler角色,这样用户就拥有了角色的权限.
　　
　　执行命令建立文件
　　
　　$ kubect create -f tyler.yml
　　
　　$ kubect create -f role-tyler.yml
　　
　　前面一节咱们使用的是命令来建立角色和已有的role绑定,这作方法简单快捷,可是不便于像这里同样进行复杂的权限编排操做,也不便于版本管理.更为复杂的权限编排建议使用yml声明式的方式建立.
　　
　　使用建立的token登录
　　
　　咱们前面说过,某一用户的secret名称为用户名-token-随机字符串格式.咱们可使用kubectl describe secret secret名称 -n=kube-system的方式查看secret,而后把token复制到dashboard登录页的token里就能够登录了.