1.生成客户端证书

（1）使用kubeadm 工具在搭建集群时，会创建一个自签名的根证书颁发机构（CA），用于签发和验证集群中各个组件以及用户的证书。CA有两个文件，分为“ca.crt”，“ca.key”，被存储在“/etc/kubernets/p ki/”目录下，现在将使用这个CA签发用户的客户端证书。   

 （2）首先为根证书创建一个JSON格式的配置文件，如下：

[root@ks-master rbac]# cat ca-config.json

{

  "signing": {

    "default": {

      "expiry": "87600h"

    },

    "profiles": {

      "kubernetes": {

        "usages": [

           "signing",

           "key encipherment",

           "server auth",

           "client auth"

        ],

        "expiry": "87600h"

      }

    }

  }

}

上述配置字段含义如下：

Default：定义默认生成证书的过期时间为87600h，即10年。

Profiles：定义一个名为”kubernetes” 的配置模板。

Usages：定义证书的用途，包括签名、密钥加密、服务端身份验证和客户端身份验证。

Expiry：定义改模板生成证书的过期时间为87600h，即10年。

     2.创建一个证书签名请求（CSR）

        配置如下：              

 [root@ks-master rbac]# cat gyq-csr.json

{

  "CN": "gyq",

  "hosts": [],

  "key": {

    "algo": "rsa",

    "size": 2048

  },

  "names": [

    {

      "C": "CN",

      "ST": "BeiJing",

      "L": "BeiJing",

      "O": "k8s",

      "OU": "System"

    }

  ]

}

           上述配置字段含义如下：

              CN：通用名称。Kubernetes通过提取该字段来标识用户身份。

             Hosts：主机名或者主机IP列表，用于限制证书的使用范围。在这里值为空，表示没有限制特定的主机或IP。

              Key：指定密钥的算法和大小。这里使用RSA算法，密钥大小为2048位。

             names：证书的详细信息包括国家（C）、省（ST）、城市（L）、组织（O）和组织单位（OU）。

3.使用cfssl工具签发客户端证书

cfssl gencert -ca=/etc/kubernetes/pki/ca.crt -ca-key=/etc/kubernetes/pki/ca.key -config=ca-config.json -profile=kubernetes gyq-csr.json | cfssljson -bare gyq

              上述命令指定了Kubernetes CA的证书 和私钥文件、CA配置文件以及CSR文件，并指定生成的证书名前缀为”gyq”

              执行完成后，将在当前目录下生成gyq.pem和gyq-key.pem文件。

   4.创建Kubeconfig配置文件

        使用kubectl工具提供的“config”子命令来创建、编辑和管理kubeconfig文件。

        (1) 使用“kubectl config set-cluster” 命令设置集群：

kubectl config set-cluster kubenetes --certificate-authority=/etc/kubernetes/pki/ca.crt --embed-certs=true --server=https://192.168.158.180:6443 --kubeconfig=gyq.kubeconfig

                 各参数含义如下：

                     Kubernetes：集群名称，可任意定义，仅用于与用户配置关联。

                     --certificate-authority：指定Kubernetes集群的根证书文件。

                     --embed-certs：是否将配置文件嵌套在配置文件中。

                     --server：指定API Server的IP地址和端口。

                     --kubeconfig：指定写入的文件名。

                      

     (2) 使用“kubectl config set-credentials” 命令设置客户端证书：

kubectl config set-credentials gyq  --client-certificate=gyq.pem --client-key=gyq-key.pem --embed-certs=true  --kubeconfig=gyq.kubeconfig

各参数含义如下：

               gyq ：用户名称，可任意自定义，仅用于与集群配置关联。

               --client-certificate：指定第一步生成的客户端证书文件。

               --client-key：指定第一步生成的客户端私钥文件。

                            --embed-certs：是否将根证书嵌套在配置文件中。

                            --kubeconfig：指定写入的文件名。

        （3）使用kubectl config set-context 命令设置上下文，并将集群配置与用户配置相关联：

kubectl config set-context kubernetes-gyq --cluster=kubernetes --user=gyq    --kubeconfig=gyq.kubeconfig

                     kubernetes-gyq：集群上下文名称，可任意定义。

                     --cluster：指定第一步设置的集群名称。

                     --user：指定第二部设置的用户名称。

                     --kubeconfig：指定写入的文件名。

        （4）使用kubectl config use-context命令设置默认使用的上下文：  

Kubectl config use-context kubernetes-gyq --kubeconfig=gyq.kubeconfig

           最终在当前目录下生成了一个名为“gyq.kubeconfig”的文件，通过该文件可以访问Kubernetes集群。

       （5）验证：

   kubectl --kubeconfig=gyq.kubeconfig get pod

           此时你会发现，”gyq”用户尚未被授予任何权限，无法执行任何资源操作，此时就需要授权。

5、创建Role

 创建Role资源，赋予一下权限：

可以对指定命名空间下的Pod、Deployment资源进行任何操作。

可以对指定命名空间下的PersistenVolumeClaim资源进行查看操作。

Role配置如下：

[root@ks-master rbac]# cat default-role.yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

  name: default-role

  namespace: default

rules:

- apiGroups: ["", "apps"]

  resources:  ["pods","deployments"]

  verbs: ["*"]

- apiGroups: [""]

  resources:  ["persistentvolumeclaims"]

  verbs: ["get"]

kubectl apply -f  default-role.yaml

上述配置在default命名空间中定义了一个名为default-role的Role对象，这表示对该命名空间的一个授权。其中的rule字段用于定义权限规则列表，每个规则包含以下三个字段。

              apiGroups：指定要授权的API组。API组是kubernetes API中的逻辑分组，用于组织和管理不同类型的资源，空字符串（“”）表示核心API组，包括Pod、Service、Node等资源类型。如果需要访问访问这些资源可以指定该API组。通过kubectl api-resources命令结果中的第三列来确认资源所属的API组。

              resources：指定访问的资源类型

              verbs：指定资源的操作方法。

       查看Role对象：

查看Role对象具体权限

6、创建RoleBinding

              创建RoleBinding资源，并将角色“default-role”与“gyq”用户进行绑定，使其具有相应的权限。如下：

 [root@ks-master rbac]# cat default-role-gyq.yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

  name: default-role-gyq

  namespace: default

subjects:

- kind: User

  name: gyq

  apiGroup: rbac.authorization.k8s.io

roleRef:

  kind: Role

  name: default-role

  apiGroup: rbac.authorization.k8s.io

kubectl apply -f  default-role-gyq.yaml

查看RoleBinding对象

此时，gyq用户已经有default-role所定义的权限了。

 7、验证与测试

              最后，测试“gyq.kubeconfig”文件的权限，确保其正确性。

已经成功创建，说明你具有该资源的创建权限。

如果尝试执行授权范围外的操作，将会提示：“权限拒绝“的错误。例如查看kube-system命名空间下的pod。

上述配置在“default”命名空间中定义了一个名为“default-role-gyq”的RoleBinding对象。Subjects字段用于定义主体，包括主体类型、名称和API组；roleRef字段用于定义关联的角色，包括角色类型、名称和API组。