前言
记得在最开始接触对称加密和非对称加密的时候是在 SSH 那一块，免密登录的过程，用到了非对称加密，也顺便了解了对称加密，后面学习HTTPS 的时候，将这两者结合了起来。经过前期的学习，我认为我对于这个内容已经掌握得不错了，但是今天在学习k8s的各组件交互底层原理时，我对于对称加密和非对称加密的理解又加深了。接下来，我就从头开始，带领你一步一步深度理解对称加密和非对称加密，以及与在k8s中的应用。
对称加密
对称加密的过程就是：通信的双方约定好使用统一的加密解密算法，以及一个salt盐作为唯一标识，发送数据前先试用加密算法和salt经过加密函数处理得到密文，接受方收到密文后使用解密算法+salt对密文解密得到明文再处理。
总之就是用一个密钥对数据进行加密传输
但是这有一个致命得危险就是黑客可能会枚举出对称加密算法，而且salt是唯一的，不会为不同的服务创建不同的salt。一旦出现信息泄漏，很可能出现如下情况：客户端和服务端之间的数据被黑客窃取并篡改，再将篡改后的数据发给服务端，因为黑客知道完整的加解密方法和salt，所以他能瞒天过海。
非对称加密
非对称加密涉及到了：公钥和私钥
非对称加密的特点就是：公钥加密，私钥解密；私钥加密，公钥解密
但是有一个问题就是：服务端发送给客户端的数据，如果使用公钥加密，那么客户端肯定解密不了，那只能使用私钥加密，这时客户端可以使用之前获取到的公钥解密，但是问题是所有人都能获取到服务端的公钥，包括黑客，所以黑客也能解密出服务端发送过来的数据，这样数据传输不安全
对称加密和非对称加密结合
客户端先获取到服务端的公钥，然后自己生成一个唯一的随机密钥A，使用公钥加密随机密钥A，这时只有服务端的私钥才能解密出随机密钥A，所以即便被加密的随机密钥A被黑客截获它也解密不出啥，服务端拿到随机密钥A之后，服务端和客户端双方约定从此之后双方的交互使用随机密钥A做对车加密的salt，只有他俩知道，所以很安全
这样还是有问题：假设黑客很厉害他有自己的公钥和私钥，而且从一开始就截取了客户端的请求，然后自己冒充服务端，发给客户端自己的公钥，这样一来，黑客能获取到双方交互的所有数据
原因就是：客户端太信任他拿到的公钥了，只要是公钥他就收，完全没有验证这个公钥是否是服务端的
引入CA机构
这其实就是HTTPS的做法，引入CA机构。
还记得HTTPS的过程吗？
- 客户端生成一个随机数
- 服务端也生成一个随机数并发给客户端，以及签名证书（含服务端公钥）
- 客户端通过浏览器内置的 CA（证书颁发机构）根证书验证服务器证书的合法性，如果符合要求就可以获取服务端公钥，这里获得的公钥肯定不是黑客的公钥（因为客户端会验证合法性，具体原因等会解释）
- 客户端再生成一个随机数，并用服务端公钥进行加密，发给服务端
- 服务端用其私钥进行解密获取随机数
- 双方通过相同的加密算法将三个随机数生成一个会话密钥
- 后面根据这一个会话密钥进行数据传输（对称加密）
简单回顾完HTTPS原理，其实还有一个小细节我一直都不知道，就是这个CA机构的签名证书以及客户端是如何验证合法性的？以及为什么黑客不可能再偷偷替换服务端公钥？
其实，CA机构有自己的公钥和私钥，大家绝对信任CA认证机构，让他做安全方面的背书。
这个过程图解其实蛮清晰的，我这里再赘述一遍：服务端请求签名证书，将公钥发给CA机构A，然后CA机构A用自己的私钥进行加密（数字签名），然后发给服务端，服务端再发给客户端，客户端有CA机构A的公钥（CA机构的公钥可以给任何人），然后客户端就可以验证拿到的公钥的合法性了，然后……
这时黑客再想插进入比如偷偷替换服务端的公钥，那不好意思，客户端只相信权威机构的公钥能解析的证书，即便黑客自己也有CA机构颁发给他自己的证书，比如说是B，虽然客户端可以解密，但是客户端也不会认，因为证书是和域名绑定的，而域名是唯一的，所以客户端只认A签名的公钥
这就完全理解了CA证书在做个什么事情了，接下来我们就应用到 Kubernetes 中，看看这些组件的安全交互是如何进行的吧
Kubernetes 中的安全验证机制
首先我们应该知道，APIServer有完备的集群安全验证机制，提供了对K8S中如Pod、Service等资源CRUD等HttpRest接口，是集群中各个组件之间数据交互的核心枢纽，具体的交互过程这里就不过多赘述了，只要知道apiserver是核心枢纽就可以了
这是基于什么实现的呢？
ApiServer采用HTTPS+CA签名证书强制双向认证，也就说是想顺利访问通ApiServer的接口需要持有对应的证书
ApiServer、Controller Manager、Scheduler有一对自己的公钥（CA给签发的证书/自签证书）和私钥，而像kubelet这种只要有CA认证机构的公钥匙证书就行（因为它始终相当于客户端）。
下面就用kubelet作为一个客户端、ApiServer作为服务端来作图
总结
这里先提醒一下，官方CA证书一般都是要钱的，所以我们可以自己做一个自签名CA证书。到这里，我相信你已经完全理解了对称加密以及非对称加密，和每个过程的危害以及如何解决的，为何要引入CA签名证书以及CA签名证书的底层原理，最后在Kubernetes的应用，希望这篇文章对你有一定帮助噢 ~
