1、Kubernetes 认证方式
Kubernetes集群的访问权限控制由API Server负责，API Server的访问权限控制由身份验证(Authentication)、授权(Authorization)和准入控制（Admission control）三个步骤组成，这个三个步骤是按序进行的（详细介绍请参见《(转)使用kubectl访问Kubernetes集群时的身份验证和授权》）。
其中身份验证这个环节它面对的输入是整个http request，它负责对来自client的请求进行身份校验，支持的方法包括：
- CA 认证，基于CA根证书签名的双向数字证书认证
- Token认证，通过Token识别每个合法的用户
- Basic认证
API Server启动时，可以指定一种Authentication方法，也可以指定多种方法。如果指定了多种方法，那么APIServer将会逐个使用这些方法对客户端请求进行验证，只要请求数据通过其中一种方法的验证，API Server就会认为Authentication成功；在较新版本kubeadm引导启动的k8s集群的API Server初始配置中，默认支持CA认证和Token认证两种身份验证方式。在这个环节，API Server会通过client证书或http header中的字段(比如ServiceAccount的JWTToken)来识别出请求的“用户身份”，包括”user”、”group”等，这些信息将在后面的授权和准入控制环节用到。
在Kubernetes中，Kubectl和API Server、Kubelet和API Server、API Server和Etcd、Kube-Scheduler和API Server、Kube-Controller-Manager和API Server以及Kube-Proxy和API Server之间是基于CA根证书签名的双向数字证书方式进行认证，此方式是最为严格和安全的集群安全配置方式，也是我们本文介绍的主角；在Kubernetes中，集成的组件和API Server之间也可以选择配置基于CA根证书签名的双向数字证书方式进行认证，比如Metrics Servser；在Kubernetes中，Pod和API Server之间如果没有配置基于CA根证书签名的双向数字证书方式进行认证的话，则默认通过Token方式（ServiceAccount的JWTToken)）进行认证。
2、Kubernetes CA 认证涉及相关知识
在详细介绍Kubernetes CA认证之前，我们先简述下和Kubernetes CA认证相关的知识。
2.1 CA证书相关知识
- 对称加密：指加密与解密使用同一密钥的方式，速度快，但密钥管理困难。
- 非对称加密：指加密和解密使用不同密钥的方式，速度慢。公钥和私钥匙一一对应的，一对公钥和私钥统称为密钥对。由公钥进行加密的密文，必须使用与该公钥配对的私钥才能解密。密钥对中的两个密钥之间具有非常密切的关系——数学上关系——公钥和私钥匙不能分布单独生成的。它有两种用途：(1)加密传输过程：公钥加密，私钥解密；(2)签名过程：私钥加密，公钥解密。
- 混合加密：将对称密钥与非对称密钥结合起来，这种系统结合了两者的优势。比如，SSL/TLS使用混合加密（Hybrid Encryption）的方式来保证通信的安全性，在混合加密中，使用非对称加密算法来协商对称密钥，然后使用对称加密算法来对通信过程中的数据进行加密和解密，以提供更高的安全性和效率。
- 数字签名：数字签名是一种用于确保数字信息的完整性、身份认证和不可抵赖性的加密技术。数字签名是基于公钥加密和非对称密钥技术实现的，常被用于验证数字文档、软件、电子邮件等的真实性和完整性。数字签名的基本原理是将原始数据通过哈希函数（Hash Function）生成一个摘要（Digest），然后使用发送者的私钥对摘要进行加密，生成数字签名。接着，将原始数据和数字签名一起传输给接收者。接收者收到数据后，使用发送者的公钥对数字签名进行解密，得到摘要。然后，接收者对接收到的原始数据使用相同的哈希函数生成另一个摘要，将两个摘要进行比较，如果两个摘要一致，则表明原始数据没有被篡改过，数字签名也是合法的，否则就表明原始数据已经被篡改过或者数字签名不合法。要正确的使用数字签名，有一个大前提，那就是用于验证签名的公钥必须属于真正的发送者。
-
证书：数字证书是基于公钥加密和非对称密钥技术实现的，通过数字证书可以验证一个数字实体的身份信息，简单来说证书就是为公钥加上数字签名。它是由数字证书颁发机构（CA，Certificate Authority）签发的一种数字文件，包含了证书持有者的身份信息和公钥等关键信息。数字证书通常包含以下信息：
- 证书颁发机构的名称和公钥。
- 证书持有者的名称、电子邮件地址和公钥等身份信息。
- 证书有效期限和用途。
- 证书颁发机构的数字签名。
- CA（证书颁发机构）：CA是一个机构，专门为其他人签发证书，这个证书保存其他人的公钥，确保了公钥的来源且没有被篡改。CA本身有自己的公私钥对，私钥用于签发其他证书，公钥用于验证证书，CA公钥同样需要保护，这就是CA证书。那么CA证书是谁签发呢，从签名的原理来看，必然存在CA自己给自己签名，这就是根CA证书。根CA是非常宝贵的，通常出于安全的考虑会签发一些中间CA证书，然后由中间CA签发最终用户证书，这样就构成了一个信任链。接收者信任某个CA证书，那么由此CA签发的证书就都被信任。公信的根CA全球只有有限的一些，它们通过第三方机构审计，具有权威性和公正性，通常操作系统或浏览器已经内置安装，由这些根CA签发的证书都会被信任。用户也可以自行安装信任的证书，其风险需要用户自己承担，一定要确保证书来源可靠。
- 根证书（自签名证书）：根证书是CA认证中心给自己颁发的证书,是信任链的起始点。
2.2 HTTPS双向认证流程
Kubernetes CA认证也叫HTTPS证书认证，其认证原理便是HTTPS双向认证，下面着重说下HTTPS双向认证流程：
1.客户端发起建⽴HTTPS连接请求，将SSL协议版本的信息发送给服务端；
2.服务器端将本机的公钥证书（server.crt）发送给客户端；
3. 客户端通过自己的根证书（ca.crt）验证服务端的公钥证书（server.crt）的合法性，取出服务端公钥。
4. 客户端将客户端公钥证书（client.crt）发送给服务器端；
5. 服务器端使⽤根证书（ca.crt）解密客户端公钥证书，拿到客户端公钥；
6. 客户端发送⾃⼰⽀持的加密⽅案给服务器端；
7. 服务器端根据⾃⼰和客户端的能⼒，选择⼀个双⽅都能接受的加密⽅案，使⽤客户端的公钥加密后发送给客户端；
8. 客户端使⽤⾃⼰的私钥解密加密⽅案，⽣成⼀个随机数R，使⽤服务器公钥加密后传给服务器端；
9. 服务端⽤⾃⼰的私钥去解密这个密⽂，得到了密钥R；
10. 服务端和客户端在后续通讯过程中就使⽤这个密钥R进⾏通信了。
注意：默认情况下，HTTPS是先进行TCP三次握手，再进行TLS四次握手。
3、Kubernetes 基于CA根证书签名的双向数字证书认证
下面以Kubectl（客户端）和API Server（服务端）认证为例，讲解基于CA根证书签名的双向数字证书认证。
3.1 API Server证书配置
使用Kubeadm初始化的Kubernetes集群中，API Server是以静态Pod的形式运行在Master Node上。 可以在Master Node上找到其定义文件/etc/kubernetes/manifests/kube-apiserver.yaml，其中启动命令参数部分如下：
spec:
containers:
- command:
- kube-apiserver
- --advertise-address=10.20.30.31
- --allow-privileged=true
- --audit-log-maxage=30
- --audit-log-maxbackup=10
- --audit-log-maxsize=100
- --audit-log-path=/data/lc/log/t-audit.log
- --authorization-mode=Node,RBAC
- --bind-address=0.0.0.0
- --client-ca-file=/etc/kubernetes/pki/ca.crt
- --enable-admission-plugins=NodeRestriction
- --enable-bootstrap-token-auth=true
- --etcd-cafile=/etc/ssl/etcd/ssl/ca.pem
- --etcd-certfile=/etc/ssl/etcd/ssl/node-node1.pem
- --etcd-keyfile=/etc/ssl/etcd/ssl/node-node1-key.pem
- --etcd-servers=https://10.20.30.31:2379
- --feature-gates=ExpandCSIVolumes=true,RotateKubeletServerCertificate=true,RemoveSelfLink=false,SuspendJob=true
- --insecure-port=0
- --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
- --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key
- --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
- --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt
- --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key
- --requestheader-allowed-names=front-proxy-client
- --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
- --requestheader-extra-headers-prefix=X-Remote-Extra-
- --requestheader-group-headers=X-Remote-Group
- --requestheader-username-headers=X-Remote-User
- --secure-port=6443
- --service-account-issuer=https://kubernetes.default.svc.cluster.local
- --service-account-key-file=/etc/kubernetes/pki/sa.pub
- --service-account-signing-key-file=/etc/kubernetes/pki/sa.key
- --service-cluster-ip-range=10.233.0.0/18
- --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
- --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
注意：”API Server” 和 “kube-apiserver” 可以视为同义词，都是 Kubernetes 中核心的 API 处理器，但 “kube-apiserver” 是 Kubernetes 中默认的 API Server 实现。
API Server作为服务端时，我们注意到有如下三个启动参数：
- –client-ca-file: 指定CA根证书文件为/etc/kubernetes/pki/ca.crt，内置CA公钥用于验证某证书是否是CA签发的证书，Kubectl和Kube-Apiserver之间认证的话，ca.crt用于验证Kubectl的客户端证书是否是CA签发的证书。
- –tls-cert-file：指定Kube-Apiserver证书文件为/etc/kubernetes/pki/apiserver.crt
- –tls-private-key-file: 指定Kube-Apiserver私钥文件为/etc/kubernetes/pki/apiserver.key
在Master Node上进入/etc/kubernetes/pki/目录：
[root@node1 pki]# pwd /etc/kubernetes/pki [root@node1 pki]# ls apiserver.crt apiserver-kubelet-client.crt ca.crt front-proxy-ca.crt front-proxy-client.crt sa.key apiserver.key apiserver-kubelet-client.key ca.key front-proxy-ca.key front-proxy-client.key sa.pub
查看CA根证书ca.crt：
[root@node1 pki]# openssl x509 -noout -text -in ca.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=kubernetes
Validity
Not Before: Apr 19 03:11:19 2022 GMT
Not After : Apr 16 03:11:19 2032 GMT
Subject: CN=kubernetes
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:bd:27:a0:73:45:58:b9:f4:90:27:53:77:02:ff:
8e:9b:f3:5a:14:d7:85:08:c8:17:8f:cb:66:54:61:
47:d3:59:3c:97:c0:bb:a0:63:c6:2a:eb:cb:07:ec:
f7:b1:06:e2:68:07:71:67:93:10:27:80:c0:2f:e2:
93:3f:34:ab:de:68:eb:3a:af:71:5e:18:71:be:e0:
06:9f:3c:97:f7:52:5e:fd:8a:2d:de:fd:bc:5e:be:
c1:51:7e:38:9b:ac:25:79:68:00:26:a4:61:e7:5f:
30:32:bb:af:39:fb:aa:58:eb:98:b6:ac:ab:31:50:
6c:bd:64:38:2d:16:5e:96:db:ba:ce:d1:ce:90:83:
a6:03:76:55:e7:af:6c:8d:2e:c5:52:18:8b:77:6f:
d3:fb:1c:cb:c9:01:8b:8f:7b:4d:a4:0c:07:8d:0d:
18:69:ac:1b:14:90:61:99:f8:8f:b8:ca:52:2e:2b:
8a:87:7a:15:5e:b1:3f:1a:1b:8e:a3:87:dc:3d:f1:
1a:3c:30:8f:cf:2e:20:eb:d9:2c:a4:5f:80:6e:cb:
f1:e1:db:68:f3:a7:40:88:f8:7f:df:0d:1d:af:ac:
f2:aa:ec:12:65:69:8e:c7:2a:42:2e:38:e6:16:b5:
1f:de:26:de:4f:e8:ec:c6:76:22:ce:3c:59:4d:46:
6e:49
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment, Certificate Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
D2:9E:9D:50:19:5E:24:92:CC:3D:A4:F3:3C:54:E4:EA:0D:FF:70:77
Signature Algorithm: sha256WithRSAEncryption
25:b2:9b:94:fb:0f:5c:50:2f:cd:4f:b3:54:97:3c:ee:b3:65:
f7:19:4a:6a:d5:ad:48:0b:f9:8e:56:0f:60:a3:7e:6e:48:62:
9b:60:1e:a3:91:d7:60:f7:96:43:5c:5b:ab:96:99:cd:2d:86:
19:de:e7:12:2e:17:2b:b6:93:50:e7:a3:74:3d:9e:cf:b5:58:
88:dc:6a:29:48:7d:57:2d:e6:a6:9b:ee:2f:ce:fa:5e:74:ba:
42:40:72:c5:fa:37:5a:03:f8:19:27:69:b3:87:be:2f:ca:ae:
9d:8e:ae:83:c3:8d:1a:45:55:23:b5:c9:d6:08:9b:6e:f7:0a:
ee:12:67:b2:24:52:e1:a8:01:35:82:0b:1d:5f:10:56:b4:b5:
ea:4a:b8:8f:0e:4c:93:dd:a8:71:37:32:27:66:20:ca:ec:5d:
f7:14:9e:8a:b7:82:18:b7:55:38:4a:a5:4b:1c:73:d7:b5:7e:
a1:f5:f8:e3:4c:ab:73:62:41:23:12:91:42:12:06:8d:84:81:
4d:30:d3:dc:14:7c:c7:a4:ab:76:fd:c7:3b:1c:42:eb:7b:23:
92:1a:11:fe:63:12:22:ea:76:d2:fd:e1:9d:0b:74:77:6b:04:
9f:a1:96:49:bc:f1:fc:9c:55:8f:19:ac:d5:f0:ac:e4:3c:d7:
bd:5e:f7:65
注意：查看证书的方式有很多，不只可以通过openssl工具，也可以通过在线SSL网站解析证书，比如：SSLeye。
验证CA根证书ca.crt证书的合法性：
[root@node1 pki]# openssl verify -CAfile ca.crt ca.crt ca.crt: OK
注意：我们知道验证证书合法性，就是用公钥验证证书的数字签名，由于CA根证书是自签名证书，公钥和数字签名信息都在ca.crt证书文件中，所以用以上命令验证ca.crt证书的合法性即可。
查看ApiServer的证书apiserver.crt：
[root@node1 pki]# openssl x509 -noout -text -in apiserver.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 7066543051370023677 (0x621167770eea4afd)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=kubernetes
Validity
Not Before: Apr 19 03:11:19 2022 GMT
Not After : Apr 16 03:11:19 2032 GMT
Subject: CN=kube-apiserver
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
......
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Authority Key Identifier:
keyid:D2:9E:9D:50:19:5E:24:92:CC:3D:A4:F3:3C:54:E4:EA:0D:FF:70:77
X509v3 Subject Alternative Name:
DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, DNS:lb.xxx.local, DNS:localhost, DNS:node1, DNS:node1.cluster.local, IP Address:10.233.0.1, IP Address:10.20.30.31, IP Address:127.0.0.1
......
验证apiserver.crt由ca.crt签发：
[root@node1 pki]# openssl verify -CAfile ca.crt apiserver.crt apiserver.crt: OK
3.2 生成Kubectl客户端私钥和证书
客户端要通过HTTPS证书双向认证的形式访问ApiServer需要生成客户端的私钥和证书，其中客户端证书的在生成时-CA参数要指定为ApiServer的CA根证书文件/etc/kubernetes/pki/ca.crt，-CAkey参数要指定为Api Server的CA key /etc/kubernetes/pki/ca.key。
下面生成客户端私钥和证书：
cd /etc/kubernetes/pki/ // 生成kubectl客户端私钥 openssl genrsa -out client.key 2048 // 基于kubectl客户端私钥生成kubectl客户端证书签名请求文件client.csr，其中CN代表k8s用户，O代表k8s组 openssl req -new -key client.key -subj "/CN=10.20.30.31/O=system:masters" -out client.csr // 基于证书请求文件、根CA证书、根CA私钥纯生成kubectl客户端证书 openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days 3650
注意 1：在 X.509 数字证书中，Subject 字段是用于表示证书拥有者的字段之一，通常包含多个子字段，用于描述证书拥有者的不同属性。下面是 Subject 字段中常见的子字段以及它们的含义：
C (Country): 表示证书拥有者所在的国家或地区的 ISO 3166-1 代码。
ST (State or Province): 表示证书拥有者所在的州或省份的全名或简称。
L (Locality): 表示证书拥有者所在的城市或城镇的名称。
O (Organization Name): 表示证书拥有者的组织名称。
OU (Organizational Unit Name): 表示证书拥有者的组织中的部门或单位名称。
CN (Common Name): 表示证书拥有者的通用名称，通常是证书关联的域名。
Email: 表示证书拥有者的电子邮件地址。
除了上述常见的子字段外，Subject 字段还可以包含其他自定义的子字段，用于描述证书拥有者的其他属性。需要注意的是，Subject 字段中的属性并非必须全部存在，具体哪些属性需要包含取决于证书颁发机构的要求。在生成kubectl客户端证书签名请求文件时，只是指定了证书拥有者的CN和O属性，分别代表k8s用户和组，其中组信息确定了kubectl客户端在k8s集群中的角色。（详细介绍请参见《(转)使用kubectl访问Kubernetes集群时的身份验证和授权》）
注意 2：.srl 是 OpenSSL 工具生成 X.509数字证书时自动生成的一个文件，用于记录证书的序列号。在生成证书时，每个证书都会被分配一个唯一的序列号，该序列号会被包含在证书中，并且存储在 .srl 文件中。由于 .srl 文件仅包含证书的序列号，因此通常可以安全地删除该文件，而不会影响现有的证书。
查看生成的kubectl客户端证书client.crt：
[root@node1 pki]# openssl x509 -noout -text -in client.crt
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
fb:f7:2d:e5:58:8c:23:d5
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=kubernetes
Validity
Not Before: Apr 8 12:15:49 2023 GMT
Not After : Apr 5 12:15:49 2033 GMT
Subject: CN=10.20.30.31, O=system:masters
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
......
Signature Algorithm: sha256WithRSAEncryption
......
验证kubectl客户端证书client.crt是由ca.crt签发：
[root@node1 pki]# openssl verify -CAfile ca.crt client.crt client.crt: OK
3.3 使用生成的Kubectl客户端私钥和证书访问ApiServer
[root@node1 pki]# kubectl --server=https://10.20.30.31:6443 > --certificate-authority=ca.crt > --client-certificate=client.crt > --client-key=client.key > get nodes NAME STATUS ROLES AGE VERSION harbor-slave Ready worker 11d v1.21.5 node1 Ready control-plane,master,worker 354d v1.21.5
注意 1：如果执行kubectl客户端命令报如下错误：
[root@node1 pki]# kubectl --server=https://10.20.30.31:6443 > --certificate-authority=ca.crt > --client-certificate=client.crt > --client-key=client.key > get nodes Error in configuration: * client-cert-data and client-cert are both specified for kubernetes-admin. client-cert-data will override. * client-key-data and client-key are both specified for kubernetes-admin; client-key-data will override请通过以下命令查看 kubectl 是否之前加入过别的 k8s 集群：
[root@node1 pki]# kubectl config view apiVersion: v1 clusters: - cluster: certificate-authority-data: DATA+OMITTED server: https://10.20.30.31:6443 name: cluster.local contexts: - context: cluster: cluster.local user: kubernetes-admin name: kubernetes-admin@cluster.local current-context: kubernetes-admin@cluster.local kind: Config preferences: {} users: - name: kubernetes-admin user: client-certificate-data: REDACTED client-key-data: REDACTED在问题节点执行如下命令，用于清空 kubectl 的配置（或者一般情况下直接删除/root/.kube/config文件即可），执行完以下命令后再执行kubectl命令便不会再报此错误。
$ /usr/bin/kubectl config unset users $ /usr/bin/kubectl config unset clusters $ /usr/bin/kubectl config unset contexts注意 2：本文主要讲解基于CA证书的双向认证方式，如果执行kubectl客户端命令报cannot list resource “nodes” in API错误，请检查kubectl客户端证书拥有者所属组关联的role是否拥有访问node资源权限。
4、总结
在Kubernetes中，Kubectl和API Server、Kubelet和API Server、API Server和Etcd、Kube-Scheduler和API Server、Kube-Controller-Manager和API Server以及Kube-Proxy和API Server之间是基于CA根证书签名的双向数字证书方式进行认证；在Kubernetes中，集成的组件和API Server之间也可以选择配置基于CA根证书签名的双向数字证书方式进行认证，比如Metrics Servser。
Kubernetes组件之间使用基于CA证书的双向认证方式可以带来以下好处：
-
更高的安全性：双向认证可以确保客户端和服务器之间的通信是双向加密的，从而提高了通信的安全性，减少了数据泄露和中间人攻击等风险。
-
认证客户端身份：使用双向认证可以让服务器验证客户端的身份，并且只有被授权的客户端才能访问服务器，从而减少了恶意攻击和未经授权的访问。
-
降低攻击风险：在双向认证中，服务器会要求客户端提供证书，这样可以避免一些恶意攻击，比如伪造证书的攻击等。
-
确保数据完整性：双向认证可以确保客户端和服务器之间的通信是完整的，没有被篡改或修改过的数据。
总之，双向认证可以提供更高的安全性和保护，减少了攻击风险，同时确保了数据的完整性和保密性，因此在 Kubernetes 中使用双向认证是一种非常有效的安全措施。
参考：Kubernetes构建自定义admission webhook
参考：(转)使用kubectl访问Kubernetes集群时的身份验证和授权
参考：给面试官上一课：HTTPS是先进行TCP三次握手，再进行TLS四次握手
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.e1idc.net
