• 创建用户认证授权的kubeconfig文件
    • 创建 CA 证书和秘钥
    • 创建 kubeconfig 文件
    • RoleBinding

    创建用户认证授权的kubeconfig文件

    当我们安装好集群后,如果想要把 kubectl 命令交给用户使用,就不得不对用户的身份进行认证和对其权限做出限制。

    下面以创建一个 devuser 用户并将其绑定到 dev 和 test 两个 namespace 为例说明。

    创建 CA 证书和秘钥

    创建 devuser-csr.json 文件

    1. {
    2. "CN": "devuser",
    3. "hosts": [],
    4. "key": {
    5. "algo": "rsa",
    6. "size": 2048
    7. },
    8. "names": [
    9. {
    10. "C": "CN",
    11. "ST": "BeiJing",
    12. "L": "BeiJing",
    13. "O": "k8s",
    14. "OU": "System"
    15. }
    16. ]
    17. }

    生成 CA 证书和私钥

    在 创建 TLS 证书和秘钥 一节中我们将生成的证书和秘钥放在了所有节点的 /etc/kubernetes/ssl 目录下,下面我们再在 master 节点上为 devuser 创建证书和秘钥,在 /etc/kubernetes/ssl 目录下执行以下命令:

    执行该命令前请先确保该目录下已经包含如下文件:

    1. ca-key.pem ca.pem ca-config.json devuser-csr.json
    1. $ cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes devuser-csr.json | cfssljson -bare devuser
    2. 2017/08/31 13:31:54 [INFO] generate received request
    3. 2017/08/31 13:31:54 [INFO] received CSR
    4. 2017/08/31 13:31:54 [INFO] generating key: rsa-2048
    5. 2017/08/31 13:31:55 [INFO] encoded CSR
    6. 2017/08/31 13:31:55 [INFO] signed certificate with serial number 43372632012323103879829229080989286813242051309
    7. 2017/08/31 13:31:55 [WARNING] This certificate lacks a "hosts" field. This makes it unsuitable for
    8. websites. For more information see the Baseline Requirements for the Issuance and Management
    9. of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
    10. specifically, section 10.2.3 ("Information Requirements").

    这将生成如下文件:

    1. devuser.csr devuser-key.pem devuser.pem

    创建 kubeconfig 文件

    1. # 设置集群参数
    2. export KUBE_APISERVER="https://172.20.0.113:6443"
    3. kubectl config set-cluster kubernetes \
    4. --certificate-authority=/etc/kubernetes/ssl/ca.pem \
    5. --embed-certs=true \
    6. --server=${KUBE_APISERVER} \
    7. --kubeconfig=devuser.kubeconfig
    8. # 设置客户端认证参数
    9. kubectl config set-credentials devuser \
    10. --client-certificate=/etc/kubernetes/ssl/devuser.pem \
    11. --client-key=/etc/kubernetes/ssl/devuser-key.pem \
    12. --embed-certs=true \
    13. --kubeconfig=devuser.kubeconfig
    14. # 设置上下文参数
    15. kubectl config set-context kubernetes \
    16. --cluster=kubernetes \
    17. --user=devuser \
    18. --namespace=dev \
    19. --kubeconfig=devuser.kubeconfig
    20. # 设置默认上下文
    21. kubectl config use-context kubernetes --kubeconfig=devuser.kubeconfig

    我们现在查看 kubectl 的 context:

    1. kubectl config get-contexts
    2. CURRENT NAME CLUSTER AUTHINFO NAMESPACE
    3. * kubernetes kubernetes admin
    4. default-context default-cluster default-admin

    显示的用户仍然是 admin,这是因为 kubectl 使用了 $HOME/.kube/config 文件作为了默认的 context 配置,我们只需要将其用刚生成的 devuser.kubeconfig 文件替换即可。

    1. cp -f ./devuser.kubeconfig /root/.kube/config

    关于 kubeconfig 文件的更多信息请参考 使用 kubeconfig 文件配置跨集群认证。

    RoleBinding

    如果我们想限制 devuser 用户的行为,需要使用 RBAC创建角色绑定以将该用户的行为限制在某个或某几个 namespace 空间范围内,例如:

    1. kubectl create rolebinding devuser-admin-binding --clusterrole=admin --user=devuser --namespace=dev
    2. kubectl create rolebinding devuser-admin-binding --clusterrole=admin --user=devuser --namespace=test

    这样 devuser 用户对 dev 和 test 两个 namespace 具有完全访问权限。

    让我们来验证以下,现在我们在执行:

    1. # 获取当前的 context
    2. kubectl config get-contexts
    3. CURRENT NAME CLUSTER AUTHINFO NAMESPACE
    4. * kubernetes kubernetes devuser dev
    5. * kubernetes kubernetes devuser test
    6. # 无法访问 default namespace
    7. kubectl get pods --namespace default
    8. Error from server (Forbidden): User "devuser" cannot list pods in the namespace "default". (get pods)
    9. # 默认访问的是 dev namespace,您也可以重新设置 context 让其默认访问 test namespace
    10. kubectl get pods
    11. No resources found.

    现在 kubectl 命令默认使用的 context 就是 devuser 了,且该用户只能操作 dev 和 test 这两个 namespace,并拥有完全的访问权限。

    可以使用我写的create-user.sh脚本来创建namespace和用户并授权,参考说明。

    关于角色绑定的更多信息请参考 RBAC——基于角色的访问控制。