Kubernetes客户端认证—— 基于CA证书的双向认证方式

news2024/11/11 5:43:48

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证书认证,执行ApiServer CA认证过滤器链逻辑的前提是客户端和服务端完成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,其中启动命令参数部分如下:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

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/目录:

1

2

3

4

5

[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:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

[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证书的合法性:

1

2

[root@node1 pki]# openssl verify -CAfile ca.crt ca.crt

ca.crt: OK

注意:我们知道验证证书合法性,就是用公钥验证证书的数字签名,由于CA根证书是自签名证书,公钥和数字签名信息都在ca.crt证书文件中,所以用以上命令验证ca.crt证书的合法性即可。

查看ApiServer的证书apiserver.crt:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

[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签发: 

1

2

[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。

下面生成客户端私钥和证书:

1

2

3

4

5

6

7

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客户端基于https双向认证方式与Kube-Apiserver服务端建立连接后,进入Kube-Apiserver认证过滤器链,首先进入CA认证过滤器(客户端证书不为空才会进入CA认证过滤器链,而本示例讲解的是基于CA证书的双向认证方式,客户端证书自然不为空),Kube-Apiserver服务端通过自己的根证书ca.crt解析Kubectl客户端证书,获取Kubectl客户端证书拥有者的CN和O属性,然后生成User结构体对象。

1

2

3

4

User: &user.DefaultInfo{

  Name:   chain[0].Subject.CommonName,  //证书CN属性值

  Groups: chain[0].Subject.Organization, //证书O属性值

 }

Kube-Apiserver服务端能够通过自己的根证书ca.crt解析Kubectl客户端证书并生成User结构体对象的话,则代表用户认证成功,不再执行其他认证方式(Token认证),之后进入Kube-Apiserver授权阶段,授权的话遍历rolebinding/clusterrolebinding,比对User结构体对象和rolebinding/clusterrolebinding中的subjects找到用户或组对应的role/clusterrole,进而确定kubectl客户端在k8s集群中的角色。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

// kubernetes-1.21.5/pkg/registry/rbac/validation/rule.go

func appliesToUser(user user.Info, subject rbacv1.Subject, namespace string) bool {

    switch subject.Kind {

    // rolebinding/clusterrolebinding中的subject类型是User类型,则比对用户对象名

    case rbacv1.UserKind:

        return user.GetName() == subject.Name

    // rolebinding/clusterrolebinding中的subject类型是Group类型,则比对用户对象组

    case rbacv1.GroupKind:

        return has(user.GetGroups(), subject.Name)

    case rbacv1.ServiceAccountKind:

        // default the namespace to namespace we're working in if its available.  This allows rolebindings that reference

        // SAs in th local namespace to avoid having to qualify them.

        saNamespace := namespace

        if len(subject.Namespace) > 0 {

            saNamespace = subject.Namespace

        }

        if len(saNamespace) == 0 {

            return false

        }

        // use a more efficient comparison for RBAC checking

        return serviceaccount.MatchesUsername(saNamespace, subject.Name, user.GetName())

    default:

        return false

    }

}

注意 2:.srl 是 OpenSSL 工具生成 X.509数字证书时自动生成的一个文件,用于记录证书的序列号。在生成证书时,每个证书都会被分配一个唯一的序列号,该序列号会被包含在证书中,并且存储在 .srl 文件中。由于 .srl 文件仅包含证书的序列号,因此通常可以安全地删除该文件,而不会影响现有的证书。

注意3:Kube-Apiserver tls客户端认证配置为RequestClientCert(客户端请求可以不发送客户端证书)。

1

2

3

4

5

6

// staging/src/k8s.io/apiserver/pkg/server/secure_serving.go:45

if s.ClientCA != nil {

        // Populate PeerCertificates in requests, but don't reject connections without certificates

        // This allows certificates to be validated by authenticators, while still allowing other auth types

        tlsConfig.ClientAuth = tls.RequestClientCert

    }

即可以不使用 SSL/TLS 加密方式、或仅使用 SSL/TLS 单向认证方式或使用 SSL/TLS 双向认证方式与Kube-Apiserver服务端建立连接,只有客户端证书不为空,才会执行CA认证过滤器链逻辑。

1

2

3

4

if config.ClientCAContentProvider != nil {

 certAuth := x509.NewDynamic(config.ClientCAContentProvider.VerifyOptions, x509.CommonNameUserConversion)

 authenticators = append(authenticators, certAuth)

}

查看生成的kubectl客户端证书client.crt:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

[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签发: 

1

2

[root@node1 pki]# openssl verify -CAfile ca.crt client.crt

client.crt: OK

3.3 使用生成的Kubectl客户端私钥和证书访问ApiServer

1

2

3

4

5

6

7

8

[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客户端命令报如下错误:

1

2

3

4

5

6

7

8

[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 集群:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

[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命令便不会再报此错误。

1

2

3

$ /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客户端证书拥有者在k8s集群中的角色是否拥有访问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 中使用双向认证是一种非常有效的安全措施。

注意 1:在 Kubernetes 官方手册中给出了 ”用户“ 的概念,Kubernetes 集群中存在的用户包括 ”普通用户“ 与 “service account” 但是 Kubernetes 没有普通用户的管理方式,只是将使用集群的证书 CA 签署的有效证书的用户都被视为合法用户。

注意 2: 对于CA双向认证方式,Kubectl客户端与Kube-Apiserver服务端完成三次握手和HTTPS双向认证后,进入Kube-Apiserver认证过滤器链,首先进入CA认证过滤器,Kube-Apiserver服务端通过自己的根证书ca.crt解析Kubectl客户端证书,获取Kubectl客户端证书拥有者的CN和O属性,然后生成User结构体对象。Kube-Apiserver服务端能够通过自己的根证书ca.crt解析Kubectl客户端证书并生成User结构体对象的话,则代表用户认证成功,不再执行其他认证方式(Token认证),之后进入Kube-Apiserver授权阶段,授权的话遍历rolebinding/clusterrolebinding,比对User结构体对象和rolebinding/clusterrolebinding中的subjects找到用户或组对应的role/clusterrole,进而确定kubectl客户端在k8s集群中的角色。

注意 3:Kube-Apiserver tls客户端认证配置为RequestClientCert(客户端请求可以不发送客户端证书),即可以不使用SSL/TLS加密方式或仅使用SSL/TLS单向认证方式或使SSL/TLS双向认证方式与Kube-Apiserver服务端建立连接,只有客户端证书不为空,才会执行CA认证过滤器链逻辑。

注意 4:使用SSL/TLS单向认证方式或使用SSL/TLS双向认证方式与Kube-Apiserver服务端建立连接的话,执行Kube-Apiserver过滤器逻辑前已经建立好SSL/TLS连接。 

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/824646.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

Docker 安装 MySQL5.6

方法一、docker pull mysql 查找Docker Hub上的mysql镜像 #docker search mysql 这里我们拉取官方的镜像,标签为5.6 #docker pull mysql:5.6 (第一次启动Docker-MySql主要是查看Docker里面MySQL的默认配置,数据位置,日志位置,配…

Flink非对齐checkpoint原理(Flink Unaligned Checkpoint)

Flink非对齐checkpoint原理(Flink Unaligned Checkpoint) 为什么提出Unaligned Checkpoint(UC)? 因为反压严重时会导致Checkpoint失败,可能导致如下问题 恢复时间长-服务效率低非幂等和非事务会导致数据…

企业电子招投标采购系统源码之电子招投标的组成 tbms

功能模块: 待办消息,招标公告,中标公告,信息发布 描述: 全过程数字化采购管理,打造从供应商管理到采购招投标、采购合同、采购执行的全过程数字化管理。通供应商门户具备内外协同的能力&…

当我们在谈Web3时,其实谈的是什么?

当我们在谈Web3时,其实谈的是什么?虽然这个问题看似简单,但是Web3的定义却十分复杂。在这篇文章中,我们将尝试用简单易懂的语言来解答这个问题,并深入探讨Web3对未来的影响。 首先,Web3是什么?简…

通讯软件013——分分钟学会Kepware OPC AE Server仿真配置

本文介绍如何使用Kepware软件仿真OPC AE Server配置。相关软件可登录网信智汇(wangxinzhihui)下载。 1、创建1个数据源:本案例采用“Graybox.Simulator.1”作为数据源。连接OPC Server数据源“Graybox.Simulator.1”。 右键点击“连通性”&am…

SpringBoot复习:(14)容器是怎么创建出来的?

在SpringApplication类的run方法。低版本和高版本的SpringBoot实现有区别。 低版本: run方法调用了createApplicationContext createApplicationContext代码如下: 它会根据contextClass来实例化一个容器然后返回. ¥¥&#xffe…

【设计模式——学习笔记】23种设计模式——命令模式Command(原理讲解+应用场景介绍+案例介绍+Java代码实现)

案例引入 有一套智能家电,其中有照明灯、风扇、冰箱、洗衣机,这些智能家电来自不同的厂家,我们不想针对每一种家电都安装一个手机App来分别控制,希望只要一个app就可以控制全部智能家电要实现一个app控制所有智能家电的需要&…

小程序开发趋势:探索人工智能在小程序中的应用

第一章:引言 小程序开发近年来取得了快速的发展,成为了移动应用开发的重要一环。随着人工智能技术的飞速发展,越来越多的企业开始探索如何将人工智能应用于小程序开发中,为用户提供更智能、便捷的服务。本文将带您一起探索人工智能…

YOLOv8+DeepSORT多目标跟踪(行人车辆计数与越界识别)视频教程

课程链接:https://edu.csdn.net/course/detail/38870 本课程使用YOLOv8和DeepSORT对视频中的行人、车辆做多目标跟踪计数与越界识别,开展YOLOv8目标检测和DeepSORT多目标跟踪强强联手的应用。 课程分别在Windows和Ubuntu系统上做项目演示,并…

基于SpringBoot+Vue的在线考试系统设计与实现(源码+LW+部署文档等)

博主介绍: 大家好,我是一名在Java圈混迹十余年的程序员,精通Java编程语言,同时也熟练掌握微信小程序、Python和Android等技术,能够为大家提供全方位的技术支持和交流。 我擅长在JavaWeb、SSH、SSM、SpringBoot等框架…

【样式】默认都不选

html <view class"u-flex u-m-t-32 u-m-b-24 u-f-s-24"><view class"u-flex" click"navFun(1)"><text>佣金率</text><image src"/static/img/pai1.png" mode"" class"u-w-28 u-h-32"…

RabbitMQ 教程 | 第7章 RabbitMQ 运维

&#x1f468;&#x1f3fb;‍&#x1f4bb; 热爱摄影的程序员 &#x1f468;&#x1f3fb;‍&#x1f3a8; 喜欢编码的设计师 &#x1f9d5;&#x1f3fb; 擅长设计的剪辑师 &#x1f9d1;&#x1f3fb;‍&#x1f3eb; 一位高冷无情的编码爱好者 大家好&#xff0c;我是 DevO…

P7883 平面最近点对(加强加强版)

题目 思路 一眼二分&#xff0c;把平面分成两部分&#xff0c;查左右两边&#xff0c;但是还有可能跨中间的线&#xff0c;所以这个也得判 代码 #include<bits/stdc.h> using namespace std; #define int long long const int maxn4e510; pair<int,int> a[maxn]…

Java版Spring Cloud+Spring Boot+Mybatis+uniapp知识付费平台讲解+免费搭建 qt

&#xfeff;Java版知识付费源码 Spring CloudSpring BootMybatisuniapp前后端分离实现知识付费平台 提供职业教育、企业培训、知识付费系统搭建服务。系统功能包含&#xff1a;录播课、直播课、题库、营销、公司组织架构、员工入职培训等。 提供私有化部署&#xff0c;免费售…

亚马逊云科技HPC解决方案,帮助浙江大学实现成本和科研任务的双丰收

浙江大学土壤学科是朱祖祥院士等几代土壤科学家共同创建的A国家重点学科&#xff0c;整体实力雄厚&#xff0c;优势特色明显&#xff0c;总体水平居国内前列。在亚马逊云科技科研创新支持计划&#xff08;Amazon Web Services Cloud Credits for Research&#xff09;的多次支持…

发掘JavaScript潜力:掌握高级技巧,成为JavaScript编程大师!

&#x1f3ac; 岸边的风&#xff1a;个人主页 &#x1f525; 个人专栏 :《 VUE 》 《 javaScript 》 ⛺️ 生活的理想&#xff0c;就是为了理想的生活 ! &#x1f4da; 前言 众所周知&#xff0c;JavaScript 是一种非常流行&#x1f525;的编程语言&#xff0c;它已经成为了网…

3000字详解:风控核心岗位及核心价值

01、信贷场景中所谓风控是什么&#xff1f; 从一个小故事说起&#xff1a; “风控是什么&#xff1f;” “你走过大桥么&#xff1f;” “桥上有栏杆么&#xff1f;” “有” “你过桥时会扶栏杆么” “一般不扶” “那栏杆是不是没必要有呢” “那还是得有啊&#xf…

SpringBoot统一功能处理(AOP思想实现)(统一用户登录权限验证 / 异常处理 / 数据格式返回)

主要是三个处理&#xff1a; 1、统一用户登录权限验证&#xff1b; 2、统一异常处理&#xff1b; 3、统一数据格式返回。 目录 一、用户登录权限校验 &#x1f345; 1、使用拦截器 &#x1f388; 1.1自定义拦截器 &#x1f388; 1.2 设置自定义拦截器 &#x1f388;创建cont…

vue3中使用原始标签制作一个拖拽和点击上传组件上传成功后展示

在Vue3中&#xff0c;可以使用<input type"file">标签来实现上传文件的功能&#xff0c;同时可以通过<div>标签来实现拖拽上传的功能。 首先&#xff0c;在template中定义一个包含<input>和<div>标签的组件&#xff1a; <template>&…

使用Vscode编辑keil工程

一、需要安装的插件 1. Keil Assistant 2. C/C 3. 中文配置&#xff1a; 二、插件配置 1. Keil Assistant 添加Keil的安装路径 接下来就可以使用vscode编辑Keil的工程了&#xff0c;调试编译和下载程序需要返回到Keil中进行操作。 三、Vscode常用快捷键 可以自定义进行配置…