嘉賓博客文章最初發表在Infracloud上，作者是Infracloud軟件開發人員Vivek Singh
https://www.infracloud.io/role-based-access-kubernetes/
如果你在Kubernetes上工作了一段時間，那麼你可能會遇到這樣一種情況：你必須為一些用戶提供對Kubernetes集群的有限訪問。例如，你可能希望用戶（比如來自開發部門的Alice）只能訪問development命名空間中的一些資源，而不能訪問其他任何資源。為了實現這種基於角色的訪問，我們在Kubernetes中使用了身份驗證和授權的概念。
一般來說，有三種用戶需要訪問Kubernetes集群：
- 開發人員/管理員：負責在集群上執行管理或開發任務的用戶。這包括升級集群或在集群上創建資源/工作負載等操作。
- 最終用戶：訪問部署在Kubernetes集群上的應用程序的用戶。這些用戶的訪問限制由應用程序本身管理。例如，運行在Kubernetes集群上的web應用程序將擁有自己的安全機制，以防止未經授權的訪問。
- 應用程序/機器人：其他應用程序可能需要訪問Kubernetes集群，通常是與集群內的資源或工作負載進行通信。Kubernetes通過使用服務帳戶（ Service Accounts）來促進這一點，這是另一篇文章的主題。這裡，我們將重點討論基於角色的訪問控制（Role Based Access Control，RBAC）。
因此，可以使用RBAC管理的用戶類別是開發人員/管理員。簡而言之，在使用RBAC時，你將創建用戶併為他們分配角色。每個角色都映射了特定的授權，從而將每個用戶限制為一組由分配給他們的角色定義的操作。到目前為止，Kubernetes還沒有任何機制來創建或管理集群內的用戶。它們需要在外部創建和管理。現在讓我們實際看看Kubernetes的RBAC。
這裡我們要做的是創建一個允許執行某些任務或僅從命名空間訪問某些資源的用戶。此用戶不應能夠執行任何其他任務或訪問任何其他資源。
我已經使用了一個minikube集群來演示這一點，但是隻要你有一個運行良好的Kubernetes集群，也會很適合你。如果你感興趣，下面是我的具體minikube版本。
<code>Kubernetes v1.14.2 on Docker 18.09.6minikube version: v1.1.0/<code>
讓我們首先創建一個命名空間。
<code>$ kubectl create namespace developmentnamespace/development created/<code>
創建用於身份驗證的客戶端證書
因為我們知道，任何客戶機都可以使用基於SSL的身份驗證機制，通過向kube-apiserver進行身份驗證來訪問Kubernetes集群。我們將不得不生成私鑰和X-509客戶端證書，以便對一個名為DevUser的用戶進行kube-apiserver身份驗證。該用戶將使用development命名空間。讓我們為DevUser創建私鑰和CSR（Certificate Signing Request，證書籤名請求）
<code>$ cd ${HOME}/.kube$ openssl genrsa -out DevUser.key 2048Generating RSA private key, 2048 bit long modulus (2 primes)$ openssl req -new -key DevUser.key -out DevUser.csr -subj "/CN=DevUser/O=development"/<code>主題（subject）的通用名稱（common name，CN）將用作身份驗證請求的用戶名。組織字段（organization field，O）將用於表示用戶的組成員關係。
當我們有了私鑰和CSR，我們就必須自簽名CSR來生成證書。我們必須提供Kubernetes集群的CA密鑰來生成證書，因為這個CA已經被minikube集群批准了。
<code>$ openssl x509 -req -in DevUser.csr -CA ${HOME}/.minikube/ca.crt -CAkey ${HOME}/.minikube/ca.key -CAcreateserial -out DevUser.crt -days 45Signature oksubject=CN = DevUser, O = developmentGetting CA Private Key/<code>請務必提供正確的CA證書和密鑰集。要了解這一點，你可以運行kubectl config view並獲取詳細信息。
配置kubectl
現在你已經有了一個用戶（DevUser）、一個私有密匙和一個證書來連接kube-apiserver，是時候在一個配置文件（即Kubeconfig）中配置這些細節了。我們可以使用這些細節來查詢來自Kubernetes集群的資源。我們可以手動配置這些細節，也可以使用kubectl客戶端對配置文件進行更改。Kubeconfig文件與其他Kubernetes資源清單一樣，有三個主要部分：clusters（集群）、contexts（上下文）和users（用戶）。正如名稱所暗示的那樣，kubeconfig文件的集群部分將包含集群的詳細信息。用戶部分將包含用戶的詳細信息，而上下文部分將包含集群和用戶之間的關係。我們在配置文件中有另一個字段，它告訴我們當前配置的上下文。如果我們在使用kubectl時不提供任何上下文，則將使用此上下文。
下面是我擁有的kubeconfig文件的一個示例。
<code># cat ~/.kube/configapiVersion: v1clusters:- cluster:certificate-authority: /home/vivek/.minikube/ca.crtserver: https://192.168.99.100:8443name: minikubecontexts:- context:cluster: minikubeuser: minikubename: minikubecurrent-context: minikubekind: Configpreferences: {}users:- name: minikubeuser:client-certificate: /home/vivek/.minikube/client.crtclient-key: /home/vivek/.minikube/client.key/<code>將條目添加到users部分
讓我們繼續添加我們創建的用戶。要在Kubeconfig文件中添加用戶，我們可以執行下面的命令（set-credentials）。請確保你提供了正確的私鑰路徑和DevUser證書。
<code>$ kubectl config set-credentials DevUser –client-certificate ${HOME}/.kube/DevUser.crt –client-key ${HOME}/.kube/DevUser.keyUser “DevUser” set./<code>現在，如果我們使用kubectl config view命令查看配置文件，我們將能夠看到在用戶部分中添加的新用戶。
<code>$ kubectl config view…users:- name: DevUseruser:client-certificate: DevUser.crtclient-key: DevUser.key- name: minikubeuser:client-certificate: /home/vivek/.minikube/client.crtclient-key: /home/vivek/.minikube/client.key/<code>
將條目添加到contexts部分
下一步是在配置文件中添加上下文，這將允許該用戶（DevUser）訪問集群中的開發命名空間。使用下面的命令執行操作。
<code>$ kubectl config set-context DevUser-context --cluster=minikube --namespace=development --user=DevUserContext "DevUser-context" created./<code>
驗證配置文件中是否添加了其他上下文。
<code># cat ~/.kube/config…contexts:- context:cluster: minikubenamespace: developmentuser: DevUsername: DevUser-context- context:cluster: minikubeuser: minikubename: minikube/<code>
向用戶添加更多權限
運行kubectl get pods將返回當前上下文minikube命名空間的默認資源。但是如果我們更改上下文DevUser-context，我們將無法訪問資源。因此，運行帶有新上下文的kubectl get pods將導致下面的錯誤：
<code>$ kubectl get pods --context=DevUser-context Error from server (Forbidden): pods is forbidden: User "DevUser" cannot list resource "pods" in API group "" in the namespace "development"/<code>
為了使這個新創建的用戶能夠只訪問development命名空間中的pods，讓我們創建一個角色，然後使用rolebinding資源將該角色綁定到DevUser。角色就像Kubernetes的其他資源一樣。它決定了一個人在扮演這個角色時能夠採取的資源和行動。使用以下清單創建角色資源：
<code>kind: RoleapiVersion: rbac.authorization.k8s.io/v1beta1metadata:name: dev-rolenamespace: developmentrules:- apiGroups: [""] resources: ["pods"]verbs: ["get", "update", "list"]/<code>
我們只提供了動詞get、update和list。這確保DevUser只能獲取、更新和列出pod上的活動，而不能做其他事情。
使用下面的清單，使用rolebinding資源將我們在上面創建的角色綁定到DevUser：
<code>kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1beta1metadata:name: dev-DevUsernamespace: developmentsubjects:- kind: Username: DevUserapiGroup: ""roleRef:kind: Rolename: dev-roleapiGroup: ""/<code>
因此，你可以在這裡看到，我們正在將角色dev-role（我們在前面創建的）與DevUser關聯起來。
在創建角色和角色綁定之後，讓我們再次列出pod。我們將成功地把它們列出來。
<code>$ kubectl get pods --context=DevUser-context No resources found.# we are not able to see any resources because we don't have any pods running# in development namespace/<code>
正如你現在看到的，我們可以使用新創建的上下文列出資源。我們知道DevUser應該只能獲取、更新和列出pod。讓我們嘗試使用這個上下文創建一個pod。
<code>$ kubectl run nginx --image=nginx --context=DevUser-context Error from server (Forbidden): deployments.apps is forbidden: User "DevUser" cannot create resource "deployments" in API group "apps" in the namespace "development"/<code>
類似地，如果試圖使用此上下文刪除正在運行的pod，則無法這樣做。如果你想讓該用戶也能夠創建和刪除，那麼只需更改分配給該用戶的角色。確保你有正確的資源和角色中的動詞。
如果希望讓其他用戶能夠訪問你的集群，請重複這些步驟。
閱讀更多 啟迪雲Tuscloud 的文章
