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定義更加細粒度的權限，也可使用系統內置的一些權限......

參考資料

• https://kubernetes.io/docs/admin/authorization/rbac/
• 如何將用戶添加到Kubernetes（kubectl）？

歡迎你們加入咱們的知識星球：Kubernetes。