Kubernetes API訪問鑑權之Basic模式

Kubernetes 支援多種模式的 API 訪問鑑權方式。包括私鑰 + 證書模式，Basic 使用者名稱密碼模式，Bearer Token 模式等。其中最常用的是基於 ServiceAccount 的私鑰 + 證書模式。不過另外兩種模式也在支援範疇，所以我們也瞭解一下，方便特殊場景下的使用。

Basic 使用者鑑權

首先，我們在 API 服務端的 /etc/kubernetes/ 目錄下新建一個 users.csv 檔案，內容如下：

[root@ksnode1 kubernetes]# cat users.csv
pass123,jemy,1007,"developer"

然後在 APIServer 的啟動命令列選項中加入選項

--basic-auth-file=/etc/kubernetes/users.csv

我們在叢集外的一個客戶端設定下訪問叢集的 Basic 賬號資訊，主要需要使用者名稱，密碼，叢集 ca 證書以及叢集的 API Server 服務地址。

$ kubectl config set-credentials jemy --username jemy --password pass123
User "jemy" set.
$ kubectl config set-cluster k8s-learning --server https://10.8.1.72:6444 --certificate-authority /etc/kubernetes/pki/env-jxx/ca.pem
$ kubectl config set-context k8s-learning-ctx --cluster k8s-learning --user jemy
$ kubectl config use-context k8s-learning-ctx

然後，我們嘗試直接訪問 nodes 命令，會發現報錯如下：

$ kubectl get nodes
Error from server (Forbidden): nodes is forbidden: User "jemy" cannot list nodes at the cluster scope

這種錯誤表示許可權驗證通過了但是沒有任何的許可權。如果是許可權驗證不通過，報錯如下：

$ kubectl get nodes
error: You must be logged in to the server (Unauthorized)

上面的這個問題主要是由 K8S 的訪問許可權管理模式決定的。K8S 的資源訪問許可權的基本處理流程分為三步：

1. Authentication 許可權驗證，簡單來說就是檢查所使用的 API 的使用者許可權是否存在，比如使用者名稱密碼是否正確，就是一個登陸許可權而已
2. Authorization 授權驗證，簡單來說就是檢查這個使用者許可權是否擁有操作 K8S 資源的許可權，對哪些資源有操作許可權，只要存在一個資源的操作許可權正確，就允許通過
3. Admission Control 准入控制，簡單來說就是檢查這個使用者對這些資源的具體操作許可權是否合法，存在一個不合法則全部拒絕操作

為了讓這個使用者能夠訪問叢集資源，我們給這個普通的使用者 jemy 授權一個系統內建的 ClusterRole：cluster-admin

$ kubectl create clusterrolebinding cluster-admin-for-jemy --clusterrole cluster-admin --user jemy
clusterrolebinding.rbac.authorization.k8s.io/cluster-admin-for-jemy created

然後再執行上面的 kubectl get nodes 即可發現節點。

$ kubectl get nodes
NAME        STATUS    ROLES     AGE       VERSION
10.8.1.75   Ready     <none>    23d       v1.11.0
10.8.1.76   Ready     <none>    23d       v1.11.0

我們使用 kubectl get clusterrole cluster-admin -o yaml 看下這個內建的 cluster-admin 定義：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: 2018-08-27T01:31:58Z
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
  resourceVersion: "43"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/cluster-admin
  uid: fd9b31a4-a998-11e8-811b-569fbff0044d
rules:
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - '*'
- nonResourceURLs:
  - '*'
  verbs:
  - '*'

這個 ClusterRole 裡面定義了所有資源的訪問，配置等操作許可權。

為了瞭解許可權控制，我們可以建立一個自己的 ClusterRole，只允許讀取節點和列舉節點資訊。

先把剛剛的 ClusterRoleBinding 刪除

$ kubectl delete  clusterrolebinding cluster-admin-for-jemy 

然後先建立我們自己的 ClusterRole

$ kubectl create clusterrole my-cluster-admin --resource nodes --verb 'get,list'
clusterrole.rbac.authorization.k8s.io/my-cluster-admin created

重新建立繫結

$ kubectl create clusterrolebinding cluster-admin-for-jemy --clusterrole my-cluster-admin --user jemy
clusterrolebinding.rbac.authorization.k8s.io/cluster-admin-for-jemy created

讀取某個節點資訊，對應 get 操作

$ kubectl get nodes 10.8.1.75
NAME        STATUS    ROLES     AGE       VERSION
10.8.1.75   Ready     <none>    23d       v1.11.0

獲取節點的列表，對應 list 操作

$ kubectl get nodes
NAME        STATUS    ROLES     AGE       VERSION
10.8.1.75   Ready     <none>    23d       v1.11.0
10.8.1.76   Ready     <none>    23d       v1.11.0

如果獲取其他的資源比如 Pods，就會失敗

$ kubectl get pods
Error from server (Forbidden): pods is forbidden: User "jemy" cannot list pods in the namespace "default"

在上面的例子中，基本介紹了普通使用者在 K8S 中的使用方法，這裡有個小的問題，如果我們改變這個使用者名稱字，需要同步叢集和客戶端的哪些資訊呢？

1. 改變 /etc/kubernetes/users.csv 中的使用者名稱 jemy 為 jemygraw，並 scp 到各個 API Server 的節點
2. 重啟 APIServer 伺服器
3. 修改客戶端~/.kube/config 裡面定義 users 的地方，把裡面的 username 改為 jemygraw
4. 在叢集中使用 kubectl edit clusterrolebinding cluster-admin-for-jemy，把裡面定義 subjects 的地方 kind:User 的節點裡面的 name 改為 jemygraw 即可
5. 然後客戶端使用 kubectl get nodes 就可以了

這個過程可以自行驗證下，順便再熟悉下上面的操作流程。

參考文件：https://kubernetes.io/docs/reference/access-authn-authz/authentication/