本篇內容主要講解“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請求。
首先創造一個角色，該角色在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以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集群如何添加用戶”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
