对称加密:最早的加密方式为 对称加密 加密解密用同一个秘钥
弊端:一旦秘钥泄露 所有通过这个秘钥加密的信息都有可能泄露
非对称加密: 两个秘钥 公钥 私钥 采用非对称加密算法 用公钥加密的文件可以用私钥解密 同时 用私钥签名可以用公钥验签
公钥顾名思义 公开的秘钥 可以分发给所有人 但私钥只能你自己持有
B通过A的公钥对文件加密发给 A 而A通过他自己的私钥解密文件
签名 :上面的流程中如果有人冒用B的身份 发消息给A 也有安全问题 所以要让A相信是B本人发的就需要 B在发信息时用自己的私钥签名(加密) A拿到后用B的公钥验签(解密) 成功则说明是B发的
在此基础上再考虑一种情况 如果B手里的A的公钥被掉包成黑客自己的公钥 并且窃取的信息 他就可以用自己的私钥解开 造成信息泄露 所以出现了CA机构 (证书授权中心)
CA机构: CA会将用户的公钥做认证 具体就CA用自己的私钥给客户的公钥做签名 再将这些签名过的数据放在网上 (证书) 客户自己的电脑一般自带CA公钥 可以验签 而且是内置在操作系统中windows中win+r 输入 certmgr.msc可以查看
示意图
https连接:https连接到一个网站实际上就是接收这个网站的秘钥(CA签名过的) 再利用秘钥进行加密通信
有时候上的网站虽然是https但是 显示为下面的就是没有被ca认证过的
实际上 https是对称加密和非对称加密综合运用的
用户会有一个对称加密秘钥 再用网站的非对称公钥加密 再把数据发给网站 网站用自己的私钥解密 但在解密后 就一直用解密后的对称秘钥做传输 直到本次连接断开 又会重复一遍 就是只在一开始用非对称加密 因为非对称加密消耗性能
k8s中的证书配置 app-config-secret.yaml中引用values里的base64编码后的文件
#app-config-secret.yaml
#quote 函数用于将字符串包装在引号中,使其成为字符串字面量 还可以写b64enc
#简单说 写成quote pod里的值就是下面的values里的原字符串 写成b64enc 会变成被编码后的值
postgresql_ca: {{ .Values.postgresql_ca | quote }}
#values.yml
postgresql_ca: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURkekNDQWwrZ0F3SUJB...."#这里是编码后的