一、集群环境

底层系统为ubuntu18.04，然后在每个node上安装k8s，并构建集群。Master node的IP地址为192.168.26.71/24，两个Worker node的IP地址为192.168.26.72/24、192.168.26.73/24。部署Calico网络插件，保证Node之间能够正常通信。

二、访问控制概述：

apiserver作为k8s集群系统的网关，是访问及管理资源对象的唯一入口，余下所有需要访问集群资源的组件，包括kube-controller-manager、kube-scheduler、kubelet和kube-proxy等集群基础组件、CoreDNS等集群的附加组件以及此前使用的kubectl命令等都要经由此网关进行集群访问和管理。这些客户端均要经由apiserver访问或改变集群状态并完成数据存储，并由它对每一次的访问请求进行合法性检验，包括用户身份鉴别、操作权限验证以及操作是否符合全局规范的约束等。所有检查均正常且对象配置信息合法性检验无误后才能访问或存入数据于后端存储系统etcd中。

对 Kubernetes API 的每个请求都经过 API 服务器中的三个阶段：身份验证、授权和准入控制。每个阶段都有明确的目的：

1. 身份验证检查用户是否是 API 的合法用户，如果是，则建立其用户；
2. 身份授权检查识别的用户是否有权限执行请求的操作；
3. 准入控制对请求执行各种额外的可配置检查以强制执行集群策略。

在每个阶段，请求都可能被拒绝——只有成功通过所有三个阶段的请求才会由 Kubernetes API 处理。本笔记将完成K8s集群的验证步骤，后续步骤将在的下一个笔记中完成。

k8s 有下面几种认证方式：

1. kubeconfig
2. token
3. oauth（第三方认证方式）
4. base-auth（1.9版本后已经废弃，使用用户名和密码认证）

三、kubeconfig认证：

1.kubeconfig文件介绍

使用kubeconfig文件进行认证。注意，并不是有一个名字叫做kubeconfig的文件，而是用于做认证的文件我们就叫做kubeconfig文件。例如aa.txt里有认证信息，其也就被称为kubeconfig文件。

在我们安装好k8s的步骤中，系统会生成一个对k8s有管理员权限的认证文件（admin.conf），原始目录在/etc/kubernetes/。后续被拷贝到$HOME/.kube/目录下的config文件：

root@vms71:~/authentication# cat /root/.kube/config
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: xxx
    server: https://192.168.26.71:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: yyy
    client-key-data: zzz

其中具体的base64转码后的数据，这里用xxx、yyy、zzz进行代替。如下一些关键字段的讲解。首先kubeconfig文件中包含三个部分：

1. 集群信息cluster：包括集群正式，即集群的地址信息；
2. 上下文信息context：关联cluster和user。同时设置默认的命名空间等信息；
3. 用户信息user：包括用户名、用户证书和私钥。

集群信息：

1. certificate-authority-data：表示集群CA证书，存放目录为/etc/kubernets/pki/，名称是ca.crt；
2. server：表示master的控制平面的连接地址。

用户信息：

1. name：用户的名称；
2. client-certificate-data：用户的证书信息（由集群CA颁发的）；
3. client-key-data：用户的私钥。

2.如何调用kubeconfig文件
默认情况下，当我们执行k8s相关的命令时，将调用这个config文件做认证。当我们删除掉对应文件后，就无法正常使用K8s的组件，可以看到如下的报错信息：

root@vms71:~/.kube# rm -rf config
root@vms71:~/.kube# kubectl get nodes
The connection to the server localhost:8080 was refused - did you specify the right host or port?

报错信息是因为kubectl直接去访问localhost:8080而非config文件中指定的集群地址。在这种情况下者我们使用–kubeconfig=命令手动指定对应的kubeconfig文件：

root@vms71:~/.kube# kubectl --kubeconfig=/etc/kubernetes/admin.conf get nodes
NAME            STATUS   ROLES                  AGE   VERSION
vms71.rhce.cc   Ready    control-plane,master   11d   v1.22.0
vms72.rhce.cc   Ready    <none>                 11d   v1.22.0
vms73.rhce.cc   Ready    <none>                 11d   v1.22.0

或者使用环境变量的形式指定使用的kubeconfig文件，则也不需要在使用kubectl命令时指定kubeconfig文件的地址：

root@vms71:~/.kube# export KUBECONFIG=/etc/kubernetes/admin.conf
root@vms71:~/.kube# kubectl get nodes
NAME            STATUS   ROLES                  AGE   VERSION
vms71.rhce.cc   Ready    control-plane,master   11d   v1.22.0
vms72.rhce.cc   Ready    <none>                 11d   v1.22.0
vms73.rhce.cc   Ready    <none>                 11d   v1.22.0

如果什么都不指定，则默认调用/root/.kube/config文件。我们重新拷贝文件回来后，又可以正常查看：

root@vms71:~/.kube# unset KUBECONFIG
root@vms71:~/.kube# cp -i /etc/kubernetes/admin.conf ./config
root@vms71:~/.kube# ls
cache  config
root@vms71:~/.kube# kubectl get nodes
NAME            STATUS   ROLES                  AGE   VERSION
vms71.rhce.cc   Ready    control-plane,master   11d   v1.22.0
vms72.rhce.cc   Ready    <none>                 11d   v1.22.0
vms73.rhce.cc   Ready    <none>                 11d   v1.22.0

如果非root用户想要使用admin的kubeconfig文件，由于没有访问权限，则需要通过root用户将其文件拷贝到非root的home目录的.kube目录下去，并命名为config：

root@vms71:~# cp /etc/kubernetes/admin.conf ~tom/.kube/config
root@vms71:~# chown -R tom.tom  ~tom/.kube/config
root@vms71:~# su tom
tom@vms71:~$ kubectl get nodes
NAME            STATUS   ROLES                  AGE   VERSION
vms71.rhce.cc   Ready    control-plane,master   11d   v1.22.0
vms72.rhce.cc   Ready    <none>                 11d   v1.22.0
vms73.rhce.cc   Ready    <none>                 11d   v1.22.0

可以看到，tom已经可以使用admin的kubeconfig文件来对K8s集群做操作。那么就出现了一个问题，也就是admin的kubeconfig文件的权限太大，tom可以轻易破坏掉当前的K8s集群。所以我们需要给tom分发另外一个，具有指定权限的kubeconfig认证文件。

3.创建自定义的kubeconfig文件
首先我们需要创建K8s管理用户的私钥和证书请求文件：

root@vms71:~/authentication# openssl genrsa -out testuser.key 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
.....................+++++
....................................................................+++++
e is 65537 (0x010001)

这里我们给一个名为testuser的K8s管理员账号（和系统管理员名字没有关系，只要系统管理员得到了这个对应K8s管理员的kubeconfig文件，即得到对应K8s管理员的权限）创建了私钥。然后利用刚生成的私有john.key 生成证书请求文件testuser.csr：

openssl req  -new -key testuser.key -out testuser.csr -subj "/CN=testuser/O=cks2021"

其中，CN=testuser制定了K8s管理员的具体名称。然后对正式请求文件进行编码：

cat testuser.csr | base64 | tr -d "\n"

编写申请证书请求文件的yaml 文件：

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: testuser
spec:
  groups:
  - system:authenticated
  signerName: kubernetes.io/kube-apiserver-client
  request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ2FqQ0NBVklDQVFBd0pURVJNQThHQTFVRUF3d0lkR1Z6ZEhWelpYSXhFREFPQmdOVkJBb01CMk5yY3pJdwpNakV3Z2dFaU1BMEdDU3FHU0liM0RRRUJBUVVBQTRJQkR3QXdnZ0VLQW9JQkFRQ3FlTlM3RVl4bUkxckNtV2FrCkMvcnM1aCsxL2FVKzNIVWd3Vmo1dGtlemdKYkFPa0p5ZlZ2Vlo4UVFsZ0J3OTFlVFk2SVlSekllTnFCMVRiQXcKVDhuQ21pRVVPbDl1TWFSWnFkVFYwdWU5dmVyb0FCdGNnUVp1RXZYUnRud2pUand4WUFWZlBCTHBtYmdUbVZSawpLVlF5RjlpcHhONm11QXBmVHZlNTJrZW1JS3JXRDErb1poMG95dHNjb1k1RlhsY0NkRlowT0w1dk43YXp3ZkRaCnA2V0NZQ2g3ZlFFSnIwWU5KS3NYTkVabDN5cERPQ0JYWXpGZ2xubGtSbmpFemZabmlQVVhReDFQc3NlOXBFNWEKNzJiQjlvRlFBTmltbXRvRVQ3enBIT2FKTnY1SGZ3RWhNTkF3dEtSZUcvaGJUK0lKakhPSE5TSk95OFQxSUZSdgpHRllkQWdNQkFBR2dBREFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBY3lOTmVSeW93dU45Zk1HSkJwemd3OFNvCk9FTGcvVkJzdlBlL08zUDRWMHNvb0w2TUlDRk9uLzhqN0pFM2ZuNFJzN1hNdlNaaUJsNnF4OGtabW9rSTRmcUYKeFV1Z1B2blYvNDhYYWRjNHJRb2E1L0NLeXpXcjN6YVV1dkcwdzh0Rk5yZnhPbk5DMVFKMHBSTlZqTVkzWU5kOQpvcXFHK1htSHgxcTR0V0w2QjJhQTdVTWJwUklGRXpKNTFsdHVuOVBqTm9uVUxLN05aZDFkWTlkSzBaOFFKMDdNCjBuQmpDVTFQZy8wc0RwTUxaeXkwU2lhTnV5aFZ1RlkyQkgxUVRqTHIzUGZ4dlU2NUJvRGJvSXZiL2FzdUkrbG4KQWZZZktiL25HcVFYUXVDTzlObGw3SnFkVjlYNkNwcEt5bC9acWpPTC9UOUYvdnhDY05leEczUkNyMGpIU3c9PQotLS0tLUVORCBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0K
  usages:
  - client auth

LS0t…LS0K是证书BASE64转码后的内容。然后我们需要通过证书请求文件来向K8s的CA申请并得到证书。

root@vms71:~/authentication# kubectl apply -f csr.yaml
certificatesigningrequest.certificates.k8s.io/testuser created

查看已经发出证书申请请求：

root@vms71:~/authentication# kubectl get csr
NAME       AGE    SIGNERNAME                            REQUESTOR          REQUESTEDDURATION   CONDITION
testuser   54s    kubernetes.io/kube-apiserver-client   kubernetes-admin   <none>              Pending

让K8s的CA批准证书：

root@vms71:~/authentication# kubectl certificate approve testuser
certificatesigningrequest.certificates.k8s.io/testuser approved

查看审批通过的证书：

root@vms71:~/authentication# kubectl get csr
NAME       AGE     SIGNERNAME                            REQUESTOR          REQUESTEDDURATION   CONDITION
testuser   102s    kubernetes.io/kube-apiserver-client   kubernetes-admin   <none>              Approved,Issued

查看并导出testuser的证书：

root@vms71:~/authentication# kubectl get csr/testuser -o jsonpath='{.status.certificate}' | base64 -d > testuser.crt
root@vms71:~/authentication# ls
csr.yaml  testuser.crt  testuser.csr  testuser.key
root@vms71:~/authentication# cat testuser.crt
-----BEGIN CERTIFICATE-----
MIIDCzCCAfOgAwIBAgIRALE+TOHCAvZTWvWjsYAEjgswDQYJKoZIhvcNAQELBQAw
FTETMBEGA1UEAxMKa3ViZXJuZXRlczAeFw0yMTEyMTIxMDIxMzJaFw0yMjEyMTIx
MDIxMzJaMCUxEDAOBgNVBAoTB2NrczIwMjExETAPBgNVBAMTCHRlc3R1c2VyMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqnjUuxGMZiNawplmpAv67OYf
tf2lPtx1IMFY+bZHs4CWwDpCcn1b1WfEEJYAcPdXk2OiGEcyHjagdU2wME/Jwpoh
FDpfbjGkWanU1dLnvb3q6AAbXIEGbhL10bZ8I048MWAFXzwS6Zm4E5lUZClUMhfY
qcTeprgKX073udpHpiCq1g9fqGYdKMrbHKGORV5XAnRWdDi+bze2s8Hw2aelgmAo
e30BCa9GDSSrFzRGZd8qQzggV2MxYJZ5ZEZ4xM32Z4j1F0MdT7LHvaROWu9mwfaB
UADYppraBE+86RzmiTb+R38BITDQMLSkXhv4W0/iCYxzhzUiTsvE9SBUbxhWHQID
AQABo0YwRDATBgNVHSUEDDAKBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB8GA1Ud
IwQYMBaAFCb8MeyuhNSPU/s+Mnzyaa0N2/TpMA0GCSqGSIb3DQEBCwUAA4IBAQBh
wBLPfzvCsMxMxGzf4yTQht4+ukgZgXWIqz9nUwyjQa2GXENZDb36Nk/NRMo0zRTg
CKyT19IXzYy+hxhE1FJpshlgkOFtj0oBmMITVaN6pcUboDD2YlVkga5y+rcRKIV8
3bJwbwRBUpUZCe95PyVybhI5UXl/m8mGdC2+GNo9Kz2nIqwU2WJkYPw23iiMig9u
o0xIv2zxMSABEh9D6hofyOGUWeUwRqZKFz5xPVEBskaHD9+K5ei3LxC5KAvZf8RQ
sXIcsS7YD427NlUEHc3Vcxf3QuG7/WiXe9ru7jqqu4FDst2/+FJN3dL6i28uOLzi
+uxwFJhOXEv+RvJ+tAix
-----END CERTIFICATE-----

接下来就是创建kubeconfig文件，首先将K8s CA的证书拷贝到同一目录下：

cp /etc/kubernetes/pki/ca.crt .

设置kubeconfig文件的集群信息，注意修改集群的地址：

kubectl config --kubeconfig=kc1 set-cluster cluster1 --server=https://192.168.26.71:6443 --certificate-authority=ca.crt --embed-certs=true

这里–embed-certs=true 的意思是把证书内容写入到此kubeconfig 文件里。接着设置用户字段，需要嵌入用户的证书和私钥文件：

kubectl config --kubeconfig=kc1 set-credentials testuser --client-certificate=testuser.crt --client-key=testuser.key --embed-certs=true

最后设置上下文字段，这里的NameSpace为default：

kubectl config --kubeconfig=kc1 set-context context1 --cluster=cluster1 --namespace=default --user=testuser

这样kubeconfig 文件就创建完毕了，如下所示。注意在context中添加current-context: "context1"这一字段。

root@vms71:~/authentication# cat kc1
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeE1URXpNREUwTURrek9Gb1hEVE14TVRFeU9ERTBNRGt6T0Zvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTHVNCndtYVFseWZEV1l4T0lObEYwMmc1YzZCcFBLYisrK0pCTHYyeG84a0MrR2sreFIrcDBFWUJHNW41VkdrYmpIOGEKVVNVQnQyQ0pVbWE1L1A3TlJ5a3VlWTZYRzlmUk1zZTZ6bkJUTkl4MUZIM2xsd3J1Y1YvTWpZL2hxNDhmQ0ZVTAowc0tHVzhveXYwQm5iUUd4ZWo3L0V2c3M3ZWI1anhORm9sSldJUDJaOGJYcVRMUFRCSkVRQVpjM241aEhOY09XCmI3bFV2a0FleEEyM1hZL2N3NWo4elNXZEZDVzlBZU5CMDhKOGRWZ1lPNGRUN1l3amMwaHBUaVcxbCtGdEVJK2IKanpaYWdnd3BaSkh0Z0I1SldWL2NrZU00ODkzQ2Zvd0dNUCs0VlNYUC9odUhGZ1RJdEM2SXd4NHhGTG5wMWswbQpvRW1SSC9BSjNIVGcycFQvbWhVQ0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZDYjhNZXl1aE5TUFUvcytNbnp5YWEwTjIvVHBNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBQmhOTXM4WE1tdzZWbWNFbTNzZgpwTDZET2ozTlF4b0RMcmlQYmQxYno4TTJmL1ZnRFF2Y2lpaVZ3MVpuY2NkQk1xTElXS24zQVRBVU5OM0VLUHNHCjFUNDVBY25ra3BIZFUyRFVabEg0UlZ0eUJvM2ZKUFFFV1pZemNFVjJOa0ZYaDYyWkUreFA0eS9lNm11YXZacy8KREgySGs5RlRvb3hmVWFpazI0MmZtUWlwQTNoWFJuUGhqMFhhMWNMd2VwanlwSGV3OTB6ekpERzNuS0pUTThmcwpsQTMrZU5MeVovWXlKa2xTaCtQMDBvZDhoWkRVUm9KVkcvb1NBNlNiaUdkMzhVSFNCMWRVbmFxNTlJSFBRS2p6CkpKQTNlaHpoVFRtQzBXMW5yMytzRWJrRTQxWUVvUUMzMXBvUEVLbytRcklOdCsxUDdPVEhiS0NxK0NrM0NOTDIKTWlFPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
    server: https://192.168.26.71:6443
  name: cluster1
contexts:
- context:
    cluster: cluster1
    namespace: default
    user: testuser
  name: context1
current-context: "context1"
kind: Config
preferences: {}
users:
- name: testuser
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURDekNDQWZPZ0F3SUJBZ0lSQUxFK1RPSENBdlpUV3ZXanNZQUVqZ3N3RFFZSktvWklodmNOQVFFTEJRQXcKRlRFVE1CRUdBMVVFQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TVRFeU1USXhNREl4TXpKYUZ3MHlNakV5TVRJeApNREl4TXpKYU1DVXhFREFPQmdOVkJBb1RCMk5yY3pJd01qRXhFVEFQQmdOVkJBTVRDSFJsYzNSMWMyVnlNSUlCCklqQU5CZ2txaGtpRzl3MEJBUUVGQUFPQ0FROEFNSUlCQ2dLQ0FRRUFxbmpVdXhHTVppTmF3cGxtcEF2NjdPWWYKdGYybFB0eDFJTUZZK2JaSHM0Q1d3RHBDY24xYjFXZkVFSllBY1BkWGsyT2lHRWN5SGphZ2RVMndNRS9Kd3BvaApGRHBmYmpHa1dhblUxZExudmIzcTZBQWJYSUVHYmhMMTBiWjhJMDQ4TVdBRlh6d1M2Wm00RTVsVVpDbFVNaGZZCnFjVGVwcmdLWDA3M3VkcEhwaUNxMWc5ZnFHWWRLTXJiSEtHT1JWNVhBblJXZERpK2J6ZTJzOEh3MmFlbGdtQW8KZTMwQkNhOUdEU1NyRnpSR1pkOHFRemdnVjJNeFlKWjVaRVo0eE0zMlo0ajFGME1kVDdMSHZhUk9XdTltd2ZhQgpVQURZcHByYUJFKzg2UnptaVRiK1IzOEJJVERRTUxTa1hodjRXMC9pQ1l4emh6VWlUc3ZFOVNCVWJ4aFdIUUlECkFRQUJvMFl3UkRBVEJnTlZIU1VFRERBS0JnZ3JCZ0VGQlFjREFqQU1CZ05WSFJNQkFmOEVBakFBTUI4R0ExVWQKSXdRWU1CYUFGQ2I4TWV5dWhOU1BVL3MrTW56eWFhME4yL1RwTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFCaAp3QkxQZnp2Q3NNeE14R3pmNHlUUWh0NCt1a2daZ1hXSXF6OW5Vd3lqUWEyR1hFTlpEYjM2TmsvTlJNbzB6UlRnCkNLeVQxOUlYell5K2h4aEUxRkpwc2hsZ2tPRnRqMG9CbU1JVFZhTjZwY1Vib0REMllsVmtnYTV5K3JjUktJVjgKM2JKd2J3UkJVcFVaQ2U5NVB5VnliaEk1VVhsL204bUdkQzIrR05vOUt6Mm5JcXdVMldKa1lQdzIzaWlNaWc5dQpvMHhJdjJ6eE1TQUJFaDlENmhvZnlPR1VXZVV3UnFaS0Z6NXhQVkVCc2thSEQ5K0s1ZWkzTHhDNUtBdlpmOFJRCnNYSWNzUzdZRDQyN05sVUVIYzNWY3hmM1F1RzcvV2lYZTlydTdqcXF1NEZEc3QyLytGSk4zZEw2aTI4dU9MemkKK3V4d0ZKaE9YRXYrUnZKK3RBaXgKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb2dJQkFBS0NBUUVBcW5qVXV4R01aaU5hd3BsbXBBdjY3T1lmdGYybFB0eDFJTUZZK2JaSHM0Q1d3RHBDCmNuMWIxV2ZFRUpZQWNQZFhrMk9pR0VjeUhqYWdkVTJ3TUUvSndwb2hGRHBmYmpHa1dhblUxZExudmIzcTZBQWIKWElFR2JoTDEwYlo4STA0OE1XQUZYendTNlptNEU1bFVaQ2xVTWhmWXFjVGVwcmdLWDA3M3VkcEhwaUNxMWc5ZgpxR1lkS01yYkhLR09SVjVYQW5SV2REaStiemUyczhIdzJhZWxnbUFvZTMwQkNhOUdEU1NyRnpSR1pkOHFRemdnClYyTXhZSlo1WkVaNHhNMzJaNGoxRjBNZFQ3TEh2YVJPV3U5bXdmYUJVQURZcHByYUJFKzg2UnptaVRiK1IzOEIKSVREUU1MU2tYaHY0VzAvaUNZeHpoelVpVHN2RTlTQlVieGhXSFFJREFRQUJBb0lCQUhWNGlGZFVjMlJhem9zMAp2RWNsUGtlTEdLVUhZWnljdkZYVEJxWWxGdW02SGFmZlBiUzViOVB5Q21qSGhReFRWVlRxbm1PT2hCblAyT2ljCm5XSGRTWkpCTmJSRHVVa3RDaTBEVy9md3V1TEVnYUJYbW9NM0lpQXVEcGp4NEQ5UUJTaWRHM2FSNWhKMWJDU04KVDFzcUk2dlZST2RRRTRIZFpzQmdvVksvK1FtZmJyTk9EdFFNTUxMMWlUSFo5dDF1cTdsY1I2cmRjQkpuTmlFNApyVHVYcUUyM1UrU1NDeUsvQWtMVEZKQ1NPS2QrVTAzZi9BRTJKS0ZBSlhtUWE5WFNLVWl2VWs0S2pFc3RYTWRLCmpodkNzY2hIZDRITll5QmtYUk4zdmxLeWhnOUV6bDZESjFyRzFxektHR1hqVktBSHhhd2krajhPTDR3RmluVEsKUDdtdUVMMENnWUVBM3YxZ3czK212WEhqOG1uY0xCc1NyZ3BUSDFqTFg3ZU5NTmt5djNlRTMzTC9CbXNvdERENwpwSGJrTktYYWNvRnNZS0JmNGlyY2lOdG9nM3Q4eW44a0ZBT0picmY1bHprWlQzdEQ0K29BT1lINHlHWHd6QmVHCm1EWlA5WGhRcXpTelMrcVhnKzlPTVJtZVNhNzN0enN6bkl5UVR5bDFZcWpYN0lwYnVkWVVxdnNDZ1lFQXc3VXgKT2EySFowcmtHTEtwbEo2Ry9oSm5XbEJrNDk1SGNERUkrWVg2by9qOWttUzhPQUVVRDFJZWJvcnZQVlgwNnRkNApiVlI0eXpSSFJ6UllaREFPRGNBc0JKSUVNMUtPN1NqR2VnL2lGeTB5d053MEc0T1Jyd1hRTXExRmQ3Z1B4cGVsCkk0U1Q2bnFtN09PVDZXYlVhWVMybGdodkcvakEzV2pEVWVNS3Q4Y0NnWUE0Q0V0TVZNTTlUMlVNQVBYR1QzYysKTEhIK3FuMVFLL3RhanZsbGkwN2tKeTFXRzQ4NjJDUWppNHlFZmppS0ZXTjZWRkpEcnFtRDZqNDA2ODdMdzI3NQphSG9jVERaM2ZXMlN2MUtyN3B6bjFuVUJSanhmekhtUnZmUVJwbzMrdDF0bWRDaG1pcmVITnZ6RFh5ZjM3dlJsCkhoMFZCMEhyN0tsMVVyOEJ6MzJhQ1FLQmdDS2NPcFplcitGK2h4UXZGSHBxQnFtTUM2Y1hMS0Izd042QWJYdmoKUzg0UHpKaEZKRndySktjSStNVEg0VU5Sbmp5aDJuUkxTZ2wxdDExS1RvOTVTQ0w2WjA1dm5EcVBVU056NEpYWgpsVHhRQy9lN2VhT2NBdm1XNTVqdXQ2aFNic2ZLTGJRNFVBaFpwSWVrUDVZNVR6dFI4eEJaY1h6YTR4REU1RFhwCkZ3NGxBb0dBVWlIWklUeWZCOFV5Z0RDdVJlcDhJdnFua3ZLWUdqSGthYXcxcHM0ajkvZjdYSzlwOXQzS3lvN0cKRWlUNnE3T0FvR0h3NWEzZ25IUDc2SkVmUVVJUjhSNXg1RFFiUElMRzViK0xzTUpzaExDVUFWOGZDRVBLMVo5QQo5WlAzdWJORnFqaUJrQXFFOUV2TWVUZjdUd21YMUVoRkZHVitCODcvT2dweXhOY2Vkanc9Ci0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==

4.验证kubeconfig文件

这个文件后续即可以拷贝给不同的用户或者不同的设备进行K8s认证。下面直接在master开始验证kubeconfig 文件：

root@vms71:~/authentication# kubectl get nodes --kubeconfig=kc1
Error from server (Forbidden): nodes is forbidden: User "testuser" cannot list resource "nodes" in API group "" at the cluster scope

可以看到有报错信息，但是报错的内容是没有权利去访问nodes的资源。原因是我们没有对用户进行授权。

四、 Token认证

我们可以使用Token的方式做用户的认证。只要用户使用K8s相关组件时给出具有对应权限的Token即可。首先，我们使用如下命令生成token。在master上

在K8s集群的master上启用token的认证方式：

root@vms71:~/authentication# openssl rand -hex 10
6a9572c132996330233d

然后我们需要将生成的随机数、用户名和ID（用，隔开）保存到一个/etc/kubernetes/pki/目录下的csv文件下（保证存放在/etc/kubernetes目录下即可）：

root@vms71:~/authentication# cat /etc/kubernetes/pki/testuser.csv
6a9572c132996330233d,testuser,3

修改apiserver的定义文件，在command一栏下加上token的参数，引用/etc/kubernetes/pki/testuser.csv文件：

vim /etc/kubernetes/manifests/kube-apiserver.yaml

- --token-auth-file=/etc/kubernetes/pki/testuser.csv

重启kubelet，完成后master也就启动了token认证：

systemctl restart kubelet

在master上，删除掉默认的kubeconfig文件后，再使用token进行测试：

root@vms71:~/authentication# rm -rf ~/.kube/config
root@vms71:~/authentication# kubectl -s https://192.168.26.71:6443 --token="6a9572c132996330233d" --insecure-skip-tls-verify=true   get nodes
Error from server (Forbidden): nodes is forbidden: User "testuser" cannot list resource "nodes" in API group "" at the cluster scope

可以看到报错信息，说明了token对应的testuser没有对应的操作权限。但是Token的认证已经通过了。

五、其他认证

1.oauth2其实是认证的接口，可以支持多种第三方认证，例如与LADP、 GITHUB等。具体可以参考：
https://www.tremolosecurity.com/products/orchestra-for-kubernetes

2.base-auth：1.9版本后已经废弃，使用用户名和密码认证。

参考资料：
《老段CKS课程》
Implementing a custom Kubernetes authentication method:https://learnk8s.io/kubernetes-custom-authentication