目錄
- 概要
- kubeconfig文件的結構
- clusters
- contexts
- users
- serviceAccount
- RBAC
- Role
- ClusterRole
概要
你有沒有想過在執行 kubectl 命令的時候，kube-apiserver 是怎么認證你的身份的？
身份認證過后是怎么鑒別你是否有權限操作所訪問的API資源的，如果想通過 API 訪問 kube-apiserver 接口，如何通過認證鑒權？
如果一個集群同時要給運維、開發、測試使用，而且各自的資源和操作互不影響應該怎么給用戶配置權限？
如果這些問題你都了然于胸，那么你可以跳過本文，否則本文將帶你學習 kubernetes 中的認證鑒權規則。
通過本文你將學習到以下知識點：
- kubeconfig 文件的結構
- RBAC 鑒權原理
- 通過 API 訪問 kube-apiserver 如何進行鑒權
kubeconfig文件的結構
kubectl 作為操作 k8s 的一個客戶端工具，只要為 kubectl 提供連接 apiserver 的配置kubeconfig文件，kubectl 可以在任何地方操作該集群，當然，若 kubeconfig 文件中配置多個集群，kubectl 也可以輕松地在多個集群之間切換。下面是kubeconfig文件結構：
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: xxx
server: https://127.0.0.1:6443
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: kubernetes-admin
name: kubernetes-admin@kubernetes
users:
- name: kubernetes-admin
user:
client-certificate-data: xxxxx
client-key-data: xxxxx
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
主要包括：clusters、contexts、users 三部分，這三個單詞都是復數形式的，暗示他們是數組結構，也就是可以配置多個，這為多集群（kubectl連接到不同集群）和多用戶（同一個集群不同用戶）切換提供了便利。
clusters
certificate-authority-data 是集群的CA證書，kubectl 使用該配置對 kube-apiserver 返回的服務端證書做校驗，用于客戶端校驗服務端的證書有效性。這里拓展下，當你在瀏覽器輸入baidu.com時，為了建立安全鏈接，baidu服務器會返回服務端證書，因為返回的服務端證書是權威機構CA簽發的，本地瀏覽器或操作系統內置了權威機構的CA，所以可以在本地找到CA對返回的服務端做合法性驗證，但是一般我們部署的k8s集群使用的都是自簽發的證書，在本地是找不到對應的CA證書對kube-apiserver返回的證書，所以需要配置集群的CA。server 表示集群的地址；name 表示集群的名字，該名字在后面的contexts會被用來關聯集群信息。
contexts
kubectl 運行時候的上下文信息，cluster（就是上面 clusters 中cluster的名字）和 user 分別表示在當前上下文下使用的是哪個用戶連接到哪個集群；name 表示上下文的名字，如果需要切換上下文，可以使用 kubectl config use-context {context name} 進行切換，切換后kubectl就會使用該上下文中定義的用戶去訪問對應的集群。
users
client-certificate-data 用于 kubectl 和 kube-apiserver 進行雙向認證加密的客戶端證書，當 kubectl 和 kube-apiserver 進行https連接時，kubectl會把該證書發送給 kube-apiserver ，后續 kubectl 使用私鑰 client-key-data 加密數據發送給 kube-apiserver時，kube-apiserver收到數據后使用 client-certificate-data 進行解密獲得明文數據。
實際上，在k8s中沒有User（用戶）概念的，或者說沒有User這樣的資源對象，kubeconfig文件的中User實際上是管理員給用戶簽發證書（users字段中的client-certificate-data）的時候使用的csr文件中指定的CN,如：
{
"CN": "david",
"hosts": ["david.com"],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "Beijing",
"L": "Beijing",
"O": "k8s",
"OU": "System"
}
]
}
kubectl在和kube-apiserver建立https連接后，kube-apiserver會取CN字段作為User（k8s本身不維護User信息），進而進行后續的鑒權工作。具體如何為用戶簽發證書，可以參考該文章，本文不作發散。
給用戶簽發完證書后，管理員就獲得了該用戶的證書（client-certificate-data）和私鑰（client-key-data），然后就可以給該用戶生成kubeconfig文件了，kubectl提供了kubectl config命令就行添加，如下：
# 添加集群信息
kubectl config set-cluster {cluster_name} \
--certificate-authority=ca.crt \
--embed-certs=true \
--server=https://172.11.11.13:6443 \
--kubeconfig=config
# 添加用戶信息
kubectl config set-credentials {username} \
--client-certificate=username.crt \
--client-key=username.key \
--embed-certs=true \
--kubeconfig=config
# 添加上下文信息
kubectl config set-context {context_name}\
--cluster={cluster_name} \
--user={username} \
--kubeconfig=config
serviceAccount
上面說了kubeconfig文件是給用戶在操作kubectl的時候認證使用的，但是如果進程（如集群內的容器）想訪問集群資源的話，用這種方式不太方便了，所以 serviceAccount 的概念應運而生，見名思意，服務賬號它存在的初衷就是給服務使用而不是給人用的。
當在集群中創建一個 serviceAccount 后，集群會自動在對應的namespace下生成一個secret，內容形式如下：
apiVersion: v1 data: ca.crt: xxx namespace: xxxxx token: xxxxxx kind: Secret metadata: xxxx type: kubernetes.io/service-account-token
- ca.crt：簽發kube-apiserver證書的ca證書，客戶端使用該ca去校驗kube-apiserver證書。
- token：該token實際為一個jwt，可以使用 jwt.io/ 查看實際的內容，token中 service-account.name 指定了用戶的實際身份，為認證和鑒權提供了信息。
- namespace：serviceAccount所屬的namespace。
每一個namespace下面，集群都會創建一個默認的serviceAccount和對應的secret，不過該secret沒有操作集群資源的權限。
如果想要在Pod內使用自己創建的sa的secret，可以在deploy中指定sa即可，如：
apiVersion: v1
kind: Deploy
metadata:
(...)
spec:
containers:
- image: nginx
(...)
serviceAccountName: {name}
這樣創建出來的Pod，Pod內的容器目錄/var/run/secrets/kubernetes.io/serviceaccount/下便會出現三個文件：
$ ls -al /var/run/secrets/kubernetes.io/serviceaccount/ total 4 drwxrwxrwt 3 root root 140 May 10 2022 . drwxr-xr-x 3 root root 4096 May 10 2022 .. lrwxrwxrwx 1 root root 13 May 10 2022 ca.crt -> ..data/ca.crt lrwxrwxrwx 1 root root 16 May 10 2022 namespace -> ..data/namespace lrwxrwxrwx 1 root root 12 May 10 2022 token -> ..data/token
如果想要驗證創建的sa對應的secret有沒有權限訪問集群的資源，可以使用如下命令：
# CACERT也可以不使用，代替的是在curl命令中加上-k選項
CACERT="xxx"
TOKEN="xxx"
namespace="xxx"
APISERVER="xxxx"
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api/v1/namespaces/${namespace}/pods
但是，有了sa后只能讓kube-apiserver知道你是誰，并不知道你有沒有權限去操作某些資源，簡而言之，目前完成的是認證步驟。就好比，進小區需要刷門禁卡，如果你是這個小區的人，那么你就可以進入該小區，但是進入小區后想要進入對應的房間，還需要進一步識別你的身份，如鑰匙、指紋、人臉識別等手段。所以，kube-apiserver還需要對請求做進一步的鑒權，才能確定是否放行。那么kubernetes是使用什么方式鑒權的呢？答案就是：RBAC。
RBAC
RBAC（Role-Based Access Control），基于角色的訪問控制。角色可以由命名空間（namespace）內的 Role 對象定義，而整個 Kubernetes 集群范圍內有效的角色則通過 ClusterRole 對象實現。
Role
Role在k8s里面也是一種資源，表示能對某個命名空間的什么資源做什么操作。一個 Role 對象只能用于授予對某一單一命名空間中資源的訪問權限。以下示例描述了 default 命名空間中的一個 Role 對象的定義，用于授予對 pod 的讀訪問權限：
kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: namespace: default name: namespace-pod-get rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"]
ClusterRole
ClusterRole 對象可以授予與 Role 對象相同的權限，但由于它們屬于集群范圍對象， 也可以使用它們授予對以下幾種資源的訪問權限：
- 集群范圍資源（例如節點，即 node）
- 非資源類型 endpoint（例如”/healthz”）
- 跨所有命名空間的命名空間范圍資源（例如 pod，需要運行命令 kubectl get pods –all-namespaces 來查詢集群中所有的 pod）
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: # 由于 ClusterRole 是集群范圍對象，所以這里不需要定義 "namespace" 字段 name: cluster-pod-get rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"]
Role和ClusterRole都表示能對什么資源做什么操作，也就是權限范圍。但是缺少一個主體，即誰有這個權限。單獨的Role和ClusterRole存在是沒有意義的，必須有一個主體去跟它做綁定才能發揮作用。于是和Role和ClusterRole對應的就有RoleBinding和ClusterRoleBinding。
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: fetch-pods namespace: default subjects: - kind: User name: test apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: namespace-pod-get apiGroup: rbac.authorization.k8s.io
- subjects: 主體，表示誰要和Role綁定。這里的Kind可以有三個選擇，User、ServiceAccount或Group，其中最常用的是前面兩種。
-
- ServiceAccount: 有沒有發現，這里和前面講的ServiceAccount產生關聯了，前面我們說ServiceAccount只能說明你是誰，并沒有說明你有什么權限，這里我們做了角色綁定后，那么ServiceAccount的權限也就有了。
- User: 就是上文提到過的證書請求文件csr中的CN字段指定的值，做了綁定后，也就是User具有相關權限了。
- Group: 可以是上文提到過的證書請求文件csr中的O字段指定的值或者name為system:開頭指定的一些系統保留組，具體可以看官方文檔具體有哪些組可以使用。
- roleRef: 角色引用，表示上述的主體和什么角色做綁定，如果是RoleBinding那么此處的角色Kind就是Role，而ClusterRoleBinding則此處的角色Kind就是ClusterRole；name 表示跟哪個Role綁定。
通過角色綁定后，服務賬號或者是用戶，都具有了Role中指定的集群資源操作權限。
以上就是kubernetes認證鑒權內容淺析的詳細內容，更多關于kubernetes認證鑒權的資料請關注其它相關文章！
