前面我們的示例中,我們創建的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 "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
前面一節我們使用的是命令來創建角色和已有的role綁定,這做方法簡單快捷,但是不便於像這里一樣進行復雜的權限編排操作,也不便於版本管理.更為復雜的權限編排建議使用yml聲明式的方式創建.
使用創建的token登陸
我們前面說過,某一用戶的secret名稱為用戶名-token-隨機字符串格式.我們可以使用kubectl describe secret secret名稱 -n=kube-system的方式查看secret,然后把token復制到dashboard登陸頁的token里就可以登陸了.