标签：怎样 cer lin ati 完整 正文 公钥加密 配置 text
对于访问kube-apiserver模块的请求来说，如果是使用http协议，则会顺利进入模块内部得到自己想要的；但是如果是用的是https，则能否进入模块内部获得想要的资源，他会首先要进行https自有的tls握手，进而进入kube-apiserver的三大控制，接下来，就让我一起研究下.....
一，对Kubernetes API访问的三大控制
参考：https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/
API服务器在2个端口上都对外提供服务：
1，Localhost Port：默认8080端口，通过这个端口的请求会绕过认证和鉴权两个控制模块，一般用于集群内部的组件之间的交互。
2，Secure Port：默认6443端口，通过这个端口的请求会经过三大控制模块，用于对外提供服务。
二，https协议的tls握手
只要你是通过Secure Port来方位api，那么你必然要建立https要求的tls链接，这是一个怎样的交互呢？让我们细细道来
1，数字证书以及网络传输加密
假设，有两个人，一个叫 小起，一个叫 小终，小起想给小终发送数据，可是怕别人截取，篡改等等一些不安全的行为，于是经历了如下的演变过程，直到最后得到了最完美的加密过程。
stage1: 对称加密
小起 ----------将数据加密，并带着能解密的钥匙，一起交给小终 -----------> 小终
问题：传输的过程中，钥匙可能被盗
stage2：非对称加密
小终：自己有一个秘钥对，公钥：对外公开； 私钥：自己保留； 由公钥加密的数据只能由私钥解密，由私钥加密的内容只能由公钥解密
小起 ----------将数据用小终的公钥加密，交给小终 -----------> 小终（由小终私钥加密的数据，用小终的公钥解密）
问题：传输的过程中，有人将数据截获，搞一堆烂七八糟的内容重新用小终的公钥加密，再发给小终。
stage2进阶：签名技术的应用
利用hash算法不可逆的特性，将正文数据进行hash计算得到摘要，当小终收到正文后同样hash计算，如果二者相同说明数据是完整的。
同时，小起还要告诉小终，这个摘要是我计算的，可不是别人计算的的。
小起 ----------将数据用小终的公钥加密，将数据用hash算法计算出摘要，并用小起的私钥对摘要进行加密（签名） -----------> 小终（用自己的公钥解密数据，用小起的公钥解密摘要）
问题：有人冒充是小起给小终发数据
stage3：数字证书
前面说了公钥/私钥都是自己家搞出来的东西，就算是被仿造了也不知道，于是将公钥"贴在第三方出具的正式文件上"（我们所说的签发数字证书）。
这样就显得有保障，因为这个正式文件上可是有第三方盖章的。但同样还要能够识别这个"章"是真正权威机构的。具体原理是：
小起，小终 <-----------从ca那里获取两样：根证书（“印章”图样），公钥（数字证书)私钥对---------CA中心（证书颁发机构）
小起 (用根证书校验小终的数字证书) <---------交换数字证书 -----------> 小终（用根证书校验小起的数字证书）
整合：对称加密结合非对称加密
考虑到效率问题，真正的业务数据是用对称加密算法加密的。所以综合以后，过程是这样的
通过stage3，我们现在互相已经有了对方准确的公钥，然后通过stage2的数据交换协商出对称加密秘钥自己保存好，再用stage1的对称加密算法（此时不需要携带解密要是）加密数据
小起 --------- 用对称加密算法加密的数据-----------> 小终
2，tls的握手前的准备
所谓的握手，其实就是我们在上一节讲述的“对称加密秘钥”的协商过程，所以再协商之前双方要先去
首先，
参考：https://baijiahao.baidu.com/s?id=1616211978225668389&wfr=spider&for=pc
---恢复内容结束---
标签：怎样 cer lin ati 完整 正文 公钥加密 配置 text
原文地址：https://www.cnblogs.com/shuiguizi/p/10947495.html
