kubernetes實戰篇之Dashboard的訪問許可權限制

周國通發表於2019-07-03
訪問許可權

系列目錄

前面我們的示例中,我們建立的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裡就可以登陸了.

相關文章