k8s添加普通用户在dashboard
转 https://blog.qikqiak.com/post/add-authorization-for-kubernetes-dashboard/
另外还可以参考这个 https://mritd.me/2018/03/20/use-rbac-to-control-kubectl-permissions/ ， https://gi thub.com/kubernetes/dashboard/issues/1991 ， https://jimmysong.io/posts/user-authentication-in-kubernetes/
前面我们在kubernetes仪表板升级之路一文中成功的将Dashboard升级到最新版本了，增加了身份认证功能，之前为了方便增加了一个admin用户，然后授予了cluster-admin的角色绑定，而该角色绑定是系统内置的一个超级管理员权限，就是也。用该用户的token登录Dashboard后会很强势，什么权限都有，想干嘛干嘛，这样的操作显然是非常危险的。接下来我们来为一个新的用户添加访问权限控制。
角色
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的英文集群级别的，可以用于：
- 集群级别的资源控制（例如节点访问权限）
- 非资源型endpoints（例如/ healthz访问）
- 所有命名空间资源控制（例如pods）
比如我们要创建一个授权某个特定命名空间或全部命名空间（取决于绑定方式）访问秘密的集群角色：
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），权限列表中包含有不同形式的待授予权限资源类型（用户，群组，服务帐户），RoleBinding适用于某个命名空间内授权，而ClusterRoleBinding适用于集群范围内的授权。
我们比如默认将命名空间的pod-reader角色授予用户简，以后这样用户该默认在命名空间中将具有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来对当前命名空间内用户，用户组或ServiceAccount进行授权，这种操作允许集群管理员在整个集群内定义一些通用的ClusterRole，然后在不同的命名空间中使用RoleBinding来引用
例如，以下RoleBinding引用了一个ClusterRole，这个ClusterRole具有整个集群内对秘密的访问权限;但是其授权用户dave只能访问开发空间中的秘密（因为RoleBinding定义在开发命名空间）
# 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样例展示了授权管理器组内所有用户在全部命名空间中对秘密进行访问
# 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
限制仪表板用户权限
有了上面的理论基础，我们就可以来新建一个用户，为该用户指定特定的访问权限了，比如我们的需求是：
- 新增一个新的用户
cnych - 用户该对只能命名空间
kube-system下面的pods状语从句：deployments进行管理
第一步新建一个ServiceAccount：
$ kubectl create sa cnych -n kube-system
然后我们新建一个角色role-cnych：（role.yaml）
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: kube-system
name: role-cnych
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
- apiGroups: ["extensions", "apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
上面注意的rules规则：管理pods状语从句：deployments的权限。
然后我们创建一个角色绑定，上面将角色的role-cnych绑定到cnych的ServiceAccount上：（角色bind.yaml）
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: role-bind-cnych
namespace: kube-system
subjects:
- kind: ServiceAccount
name: cnych
namespace: kube-system
roleRef:
kind: Role
name: role-cnych
apiGroup: rbac.authorization.k8s.io
执行分别两个上面yaml文件：
$ kubect create -f role.yaml
$ kubect create -f role-bind.yaml
接下来该怎么做和前面一样的，我们只需要拿到？cnych这个ServiceAccount的token就可以登录Dashboard了：
$ kubectl get secret -n kube-system |grep cnych
cnych-token-nxgqx kubernetes.io/service-account-token 3 47m
$ kubectl get secret cnych-token-nxgqx -o jsonpath={.data.token} -n kube-system |base64 -d
# 会生成一串很长的base64后的字符串
在然后dashboard登录页面上直接使用上面得到的token字符串即可登录，登录过后能看到下面的页面。
的英文这因为当前的这个token对应的用户没有被授予访问默认命名空间的权限，所以会出现这种提示，我们然后访问kube-system这个命名空间试下看看（https：//开头<dashboard_url>！？/＃/荚命名空间= KUBE-系统）：
我们可以看到可以访问pod列表了，但是也会有一些其他额外的提示：事件被禁止：用户“system：serviceaccount：kube-system：cnych”无法列出名称空间“kube-system”中的事件，这是因为登录当前只用被授权了访问pod状语从句：deployment的权限，同样的，下访问deployment看看可以了吗？
同样的，你可以根据自己的需求来对访问用户的权限进行限制，自己可以通过Role定义更加细粒度的权限，也可以使用系统内置的一些权限......
参考资料
欢迎大家加入我们的知识星球：Kubernetes。
