API Server的授權管理

API Server 內部通過使用者認證後，然後進入授權流程。對合法使用者進行授權並且隨後在使用者訪問時進行鑑權，是許可權管理的重要環節。API Server 目前支援一下幾種授權策略。

• Always Deny： 表示拒絕所有的請求，一般使用者測試。
• Always Allow：允許接收所有請求，如果叢集不需要授權流程，則可以採用該策略，這也是Kubernetes的預設配置。
• ABAC： 基於屬性的訪問控制，表示使用使用者配置的授權規則對使用者請求進行匹配和控制。
• Webhook：通過呼叫外部REST服務對使用者進行授權。
• RBAC：Role-Base Access Control， 基於角色的訪問空。

授權管理配置

我們來看一下kubectl使用的配置檔案。

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: https://172.16.138.44:8443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-[email protected]
current-context: kubernetes-
 
[email protected]
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

授權管理也是kubernetes的標準資源物件，頂層配置有

• clusters  配置多個叢集
• contexts 配置多個上下文
• users 配置多個使用者
• current-context 當前預設上下文

當前配置檔案詳解，clusters中有一個叢集名字叫kubernetes，users中有一個叫kubernetes-admin

主要講解RBAC

Role和ClusterRole

 對某個kubernetes的物件（Objects）上施加的一種行為（get post delete 等），我們稱為Permissions，把Permissions授於Role，就是一個角色了。能夠扮演為主體的就是我們之前講到的serviceAccount。UserAccount和ServiceAccount。

角色可以由名稱空間（namespace）內的Role物件定義，而整個Kubernetes叢集範圍內有效的角色則通過ClusterRole物件實現。一個Role物件只能用於授予對某一單一名稱空間中資源的訪問許可權。

ClusterRole物件可以授予與Role物件相同的許可權，但由於它們屬於叢集範圍物件， 也可以使用它們授予對以下幾種資源的訪問許可權：

• 叢集範圍資源（例如節點，即node）
• 非資源型別endpoint（例如”/healthz”）
• 跨所有名稱空間的名稱空間範圍資源（例如pod，需要執行命令kubectl get pods --all-namespaces來查詢叢集中所有的pod）

定義一個讀取Pods 的Role

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pods-reader
  namespace: default
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch

定義一個clusterrole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: clusterrole-reader
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch

 RoleBinding和ClusterBinding

 RoleBinding將定義的Role授權給一個或者一組使用者，RoleBinding就包含了一組相關主體（即subject, 包括使用者——User、使用者組——Group、或者服務賬戶——Service Account）以及對被授權的Role的引用。在名稱空間中可以通過RoleBinding物件授予許可權，而叢集範圍的許可權授予則通過ClusterRoleBinding物件完成。如下圖：

解釋：NamespaceA中的Role繫結在RoleBinding上並授權給User1,即User1就擁又了NamespaceA的許可權。叢集ClusterRole通過ClusterRoleBinding授權給User1,即User1擁有叢集許可權。NamespaceB中的RoleBinding引用了叢集中ClusterRole，RoleBinding授權給User2 User3，即User2 User3擁有NamespaceB的許可權。這是大家會又給疑問，為什麼RoleBinding非要引用了ClusterRole，而不在NamespaceB下建立一個Role呢？因為當我們又很多Namespace的時候，我們這樣需要建立很多的Role,為了重複建立Role，我們可以建立一個ClusterRole來讓各個Namespace來用RoleBinding去引用，這樣就避免重新建立Role了。大大減少運維的工作。

RoleBinding樣例

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: jaxzhai-rolebinding
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pods-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: jaxzhai

roleRef

• apiGroup
• kind
• name

subjects

• apiGroup
• kind
• name
• namespace

ClusterRoleBinding樣例

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: read-pods-all
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: clusterrole-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: jaxzhai

kubectl describe clusterrolebinding read-pods-all
Name:         read-pods-all
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"rbac.authorization.k8s.io/v1beta1","kind":"ClusterRoleBinding","metadata":{"annotations":{},"name":"read-pods-all","namespace":""},"role...
Role:
  Kind:  ClusterRole
  Name:  clusterrole-reader
Subjects:
  Kind  Name     Namespace
  ----  ----     ---------
  User  jaxzhai  

RoleBind 引用ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: clusterrole-test
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: clusterrole-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: jaxzhai