# 創建用戶認證授權的kubeconfig文件 當我們安裝好集群后，如果想要把 kubectl 命令交給用戶使用，就不得不對用戶的身份進行認證和對其權限做出限制。 下面以創建一個 devuser 用戶并將其綁定到 dev 和 test 兩個 namespace 為例說明。 ## 創建 CA 證書和秘鑰 **創建 `devuser-csr.json ` 文件** ```json { "CN": "devuser", "hosts": [], "key": { "algo": "rsa", "size": 2048 }, "names": [ { "C": "CN", "ST": "BeiJing", "L": "BeiJing", "O": "k8s", "OU": "System" } ] } ``` **生成 CA 證書和私鑰** 在 [創建 TLS 證書和秘鑰](../practice/create-tls-and-secret-key.md) 一節中我們將生成的證書和秘鑰放在了所有節點的 `/etc/kubernetes/ssl` 目錄下，下面我們再在 master 節點上為 devuser 創建證書和秘鑰，在 `/etc/kubernetes/ssl` 目錄下執行以下命令： 執行該命令前請先確保該目錄下已經包含如下文件： ``` ca-key.pem ca.pem ca-config.json devuser-csr.json ``` ```bash $ cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes devuser-csr.json | cfssljson -bare devuser 2017/08/31 13:31:54 [INFO] generate received request 2017/08/31 13:31:54 [INFO] received CSR 2017/08/31 13:31:54 [INFO] generating key: rsa-2048 2017/08/31 13:31:55 [INFO] encoded CSR 2017/08/31 13:31:55 [INFO] signed certificate with serial number 43372632012323103879829229080989286813242051309 2017/08/31 13:31:55 [WARNING] This certificate lacks a "hosts" field. This makes it unsuitable for websites. For more information see the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org); specifically, section 10.2.3 ("Information Requirements"). ``` 這將生成如下文件： ``` devuser.csr devuser-key.pem devuser.pem ``` ## 創建 kubeconfig 文件 ```bash # 設置集群參數 export KUBE_APISERVER="https://172.20.0.113:6443" kubectl config set-cluster kubernetes \ --certificate-authority=/etc/kubernetes/ssl/ca.pem \ --embed-certs=true \ --server=${KUBE_APISERVER} \ --kubeconfig=devuser.kubeconfig # 設置客戶端認證參數 kubectl config set-credentials devuser \ --client-certificate=/etc/kubernetes/ssl/devuser.pem \ --client-key=/etc/kubernetes/ssl/devuser-key.pem \ --embed-certs=true \ --kubeconfig=devuser.kubeconfig # 設置上下文參數 kubectl config set-context kubernetes \ --cluster=kubernetes \ --user=devuser \ --namespace=dev \ --kubeconfig=devuser.kubeconfig # 設置默認上下文 kubectl config use-context kubernetes --kubeconfig=devuser.kubeconfig ``` 我們現在查看 kubectl 的 context： ```bash kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE * kubernetes kubernetes admin default-context default-cluster default-admin ``` 顯示的用戶仍然是 admin，這是因為 kubectl 使用了 `$HOME/.kube/config` 文件作為了默認的 context 配置，我們只需要將其用剛生成的 `devuser.kubeconfig` 文件替換即可。 ```bash cp -f ./devuser.kubeconfig /root/.kube/config ``` 關于 kubeconfig 文件的更多信息請參考 [使用 kubeconfig 文件配置跨集群認證](../guide/authenticate-across-clusters-kubeconfig.md)。 ## RoleBinding 如果我們想限制 devuser 用戶的行為，需要使用 RBAC創建角色綁定以將該用戶的行為限制在某個或某幾個 namespace 空間范圍內，例如： ```bash kubectl create rolebinding devuser-admin-binding --clusterrole=admin --user=devuser --namespace=dev kubectl?create?rolebinding?devuser-admin-binding?--clusterrole=admin?--user=devuser?--namespace=test ``` 這樣 devuser 用戶對 dev 和 test 兩個 namespace 具有完全訪問權限。 讓我們來驗證以下，現在我們在執行： ```bash # 獲取當前的 context kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE * kubernetes kubernetes devuser dev * kubernetes kubernetes devuser test # 無法訪問 default namespace kubectl get pods --namespace default Error from server (Forbidden): User "devuser" cannot list pods in the namespace "default". (get pods) # 默認訪問的是 dev namespace，您也可以重新設置 context 讓其默認訪問 test namespace kubectl get pods No resources found. ``` 現在 kubectl 命令默認使用的 context 就是 devuser 了，且該用戶只能操作 dev 和 test 這兩個 namespace，并擁有完全的訪問權限。 可以使用我寫的[create-user.sh腳本](https://github.com/rootsongjc/kubernetes-handbook/blob/master/tools/create-user/create-user.sh)來創建namespace和用戶并授權，參考[說明](../tools/create-user/README.md)。 關于角色綁定的更多信息請參考 [RBAC——基于角色的訪問控制](rbac.md)。