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

最新推荐文章于 2025-03-18 09:27:14 发布

2301_76429513

最新推荐文章于 2025-03-18 09:27:14 发布

阅读量792

点赞数

文章标签： kubernetes 容器云原生

本文链接：https://blog.csdn.net/2301_76429513/article/details/131996981

版权

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进⾏通信了。