共計 3672 個字符，預計需要花費 10 分鐘才能閱讀完成。
本篇內容主要講解“Kubernetes 集群如何添加用戶”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓丸趣 TV 小編來帶大家學習“Kubernetes 集群如何添加用戶”吧!
Kubernetes 中的用戶
K8S 中有兩種用戶 (User)——服務賬號(ServiceAccount) 和普通意義上的用戶(User) ServiceAccount 是由 K8S 管理的，而 User 通常是在外部管理，K8S 不存儲用戶列表——也就是說，添加 / 編輯 / 刪除用戶都是在外部進行，無需與 K8S API 交互，雖然 K8S 并不管理用戶，但是在 K8S 接收 API 請求時，是可以認知到發出請求的用戶的，實際上，所有對 K8S 的 API 請求都需要綁定身份信息(User 或者 ServiceAccount)，這意味著，可以為 User 配置 K8S 集群中的請求權限。
ServiceAccount 是 K8S 內部資源，而 User 是獨立于 K8S 之外的。從它們的本質可以看出：
User 通常是人來使用，而 ServiceAccount 是某個服務 / 資源 / 程序使用的。
User 獨立在 K8S 之外，也就是說 User 是可以作用于全局的，在任何命名空間都可被認知，并且需要在全局唯一。
ServiceAccount 作為 K8S 內部的某種資源，是存在于某個命名空間之中的，在不同命名空間中的同名 ServiceAccount 被認為是不同的資源。
K8S 不會管理 User，所以 User 的創建 / 編輯 / 注銷等，需要依賴外部的管理機制。
這里說的添加用戶指的是普通意義上的用戶，即存在于集群外的用戶，為 k8s 的使用者。
實際上叫做添加用戶也不準確，用戶早已存在，這里所做的只是使 K8S 能夠認知此用戶，并且控制此用戶在集群內的權限。
用戶驗證
盡管 K8S 認知用戶靠的只是用戶的名字，但是只需要一個名字就能請求 K8S 的 API 顯然是不合理的，所以依然需要驗證此用戶的身份，在 K8S 中，有以下幾種驗證方式：
X509 客戶端證書 客戶端證書驗證通過為 API Server 指定 –client-ca-file=xxx 選項啟用，API Server 通過此 ca 文件來驗證 API 請求攜帶的客戶端證書的有效性，一旦驗證成功，API Server 就會將客戶端證書 Subject 里的 CN 屬性作為此次請求的用戶名。
靜態 token 文件 通過指定 –token-auth-file=SOMEFILE 選項來啟用 bearer token 驗證方式，引用的文件是一個包含了 token, 用戶名, 用戶 ID 的 csv 文件 請求時，帶上 Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269 頭信息即可通過 bearer token 驗證
靜態密碼文件 通過指定 –basic-auth-file=SOMEFILE 選項啟用密碼驗證，類似的，引用的文件時一個包含 密碼, 用戶名, 用戶 ID 的 csv 文件 請求時需要將 Authorization 頭設置為 Basic BASE64ENCODED(USER:PASSWORD)。
這里只介紹客戶端驗證。
為用戶生成證書
首先需要為此用戶創建一個私鑰：
openssl genrsa -out tom.key 2048接著用此私鑰創建一個 csr(證書簽名請求)文件，其中我們需要在 subject 里帶上用戶信息(CN 為用戶名，O 為用戶組)，其中 / O 參數可以出現多次，即可以有多個用戶組：
openssl req -new -key tom.key -out tom.csr -subj /CN=tom/O=MGM找到 K8S 集群 (API Server) 的 CA 證書文件，其位置取決于安裝集群的方式，通常會在 /etc/kubernetes/pki/ 路徑下，會有兩個文件，一個是 CA 證書(ca.crt)，一個是 CA 私鑰(ca.key)。通過集群的 CA 證書和之前創建的 csr 文件，來為用戶頒發證書：
openssl x509 -req -in tom.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out tom.crt -days 365-CA 和 -CAkey 參數需要指定集群 CA 證書所在位置，-days 參數指定此證書的過期時間，這里為 365 天。
最后將證書 (tom.crt) 和私鑰 (tom.key) 保存起來，這兩個文件將被用來驗證 API 請求。
為用戶添加基于角色的訪問控制(RBAC)
首先創造一個角色，該角色在 acp 命名空間下擁有所有權限：
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: acp
name: acp-admin
rules:
- apiGroups: [*]
resources: [*]
verbs: [*]將角色和用戶 tom 綁定：
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: acp-admin-binding
namespace: acp
subjects:
- kind: User
name: tom
apiGroup:
roleRef:
kind: Role
name: acp-admin
apiGroup: 如 yaml 中所示，RoleBinding 資源創建了一個 Role-User 之間的關系，roleRef 節點指定此 RoleBinding 所引用的角色，subjects 節點指定了此 RoleBinding 的受體，可以是 User，也可以是前面說過的 ServiceAccount，在這里只包含了名為 tom 的用戶。參考：https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding
為 kubectl 配置用戶
現在我們想要通過 kubectl 以 tom 的身份來操作集群，需要將 tom 的認證信息添加進 kubectl 的配置，即~/.kube/config 中，通過以下命令將用戶 tom 的驗證信息添加進 kubectl 的配置：
kubectl config set-credentials tom --client-certificate=tom.crt --client-key=tom.key添加完成后在~/.kube/config 可以看到新增了：
users:
- name: tom
user:
client-certificate: /root/k8s/tom.crt
client-key: /root/k8s/tom.key用下面命令添加一個 context 配置：
kubectl config set-context tom --cluster=kubernetes --namespace=acp --user=tom添加完成后在~/.kube/config 可以看到新增了：
contexts:
- context:
cluster: kubernetes
namespace: acp
user: tom
name: tom通過 kubectl config get-contexts 命令也可以查到當前 kubectl 所配置的 context 信息：
[root@master1 k8s]# kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* kubernetes-admin@kubernetes kubernetes kubernetes-admin
tom kubernetes tom acp使用剛剛新創建的 context：
# 方式一：切換 context
kubectl config use-context tom
#方式二：使用該 context
kubectl --context=tom 命令在集群外部使用
將 tom.crt/tom.key 的內容用 BASE64 編碼：
cat tom.crt | base64 --wrap=0
cat tom.key | base64 --wrap=0將獲取的編碼后的文本復制進~/.kube/config 文件中：
contexts:
- context:
cluster: kubernetes
namespace: acp
user: tom
name: tom
users:
- name: tom
user:
client-certificate-data: ...
client-key-data: ...到此，相信大家對“Kubernetes 集群如何添加用戶”有了更深的了解，不妨來實際操作一番吧！這里是丸趣 TV 網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
