Kubernetes之RBAC

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-admin@kubernetes
current-context: kubernetes-admin@kubernetes
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的用戶，contexts有一個叫kubernetes-admin@kubernetes的上下文配置，而關聯起來的集羣是kubernetes和user名爲kubernetes-admin的關係，而前面的上下文配置是使用的kubernetes-admin@kubernetes。

主要講解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