Istio 安全管理 加密证书中心
1 tls认证
2 设置ACL 允许哪些客户端可以访问 哪些客户端不能访问
3 istio里面的认证
加密是可以分为三种类型
- 对称加密（加密和解密用的是同一个密钥）
- 非对称加密
- 哈希函数
密码给到B那么B是打不开的，因为这个数据是被加密的，这个密码即使被别人截获了也没用的，对于B来说也是打不开的。A要想办法去告诉B说加密密码是haha001。
现在A不知道如何将密码告诉给B，所以这是一个问题。
加密和解密使用相同的密钥 优点：加密数据的速度比较快（适合加密大数据） 缺点：密钥不知该如何告诉对方（如果密钥传递给对方那么很容易被截获了）
非对称加密有两个密钥：
- 公钥：可以公开的（谁都可以去获取的，安全性没有那么强而已）
- 私钥：保存好，不可让别人获取
- 数据加密：公钥加密，私钥解密
- 数字签名：私钥加密，公钥解密
A要发送数据给B，那么A要获取B的公钥，也就是A有了B的公钥。有了公钥之后会去加密需要传输的数据，完成之后将密钥发送给B，这个过程是不怕被别人截获的。截获了必须使用B的私钥去解密，所以私钥被保护好，不在其他人手上。
截获了因为没有私钥，这个时候数据传输到了B，那么B使用私钥去解密就行了。
可以看到对称加密时候加密大数据，非对称加密算法不适合加密大数据，所以可以将非对称加密算法和对称加密算法整合在一块去使用。
对称和非对称结合使用
A使用对称算法加密了数据发送给B，这个时候B是不知道如何解密，因为A不知道如何将对称算法传输给B。
整合了非对称加密算法就容易多了，首先B会将自己的公钥发送给A，A会使用B的公钥加密对称算法的密钥，注意不是加密原始数据。
加密了对称算法的密钥之后，记住是使用B的公钥加密的，然后再传输给B，这个传输过程当中是安全的，被别人截获了也没用，被别人截获了之后也解不开，因为使用B的私钥才可以解开。
B收到使用自己公钥加密的数据之后，然后使用私钥对其解密，之后就得到了对称加密算法的密钥。最后就可以去解密对称加密算法的密钥了。
注意：这里使用B的公钥加密的是对称算法的密钥，而不是加密的原始数据。
上面都有一个前提是B将公钥发送给A，A就真的以为是B的公钥。
中间人攻击
B的公钥要传送给A的时候，这一步就被C给截获了，对于C来说也有自己的公钥和私钥的。C将自己的公钥传递给A，这叫伪装。它伪装为B的公钥。其实也就是被中间人调包了。
现在A是不明真相的群众不知道真假，用被调包的公钥去加密对称算法的密钥。在传输给B的过程当中又被截获了。之后C使用自己的私钥就完全可以解开这里面的数据。以为C截获了B的公钥，然后又使用B的公钥加密一份数据给B，这样就不存在解不开的情况。
上面就是所谓的中间人攻击。（1）泄露了数据，可以随意去看A和B之间的数据了。（2）c也可能会去修改其中的数据。
上面出现问题的环节就在第一步出现问题了。因为A就是不明真相的吃瓜群众。不能说别人发送给你，你就相信，发送给你B的公钥你就信任这个是B的公钥吗？这里是容易受到中间人攻击的。
这里就需要证书中心了。
数字签名
你去签合同，怎么证明才是你签名的合同呢？那就需要手印了。
所谓的数字签名就是给你发数据的时候给你按了一个手印，证明这个数据就是我的，这是我发送的，上面有我的手印。
数据签名就是用来验证数据的真伪，不去做数据的加密。
B要发送数据给A，要发送给A那么得要向A去证明数据就是B发送的。这个时候A依然是需要B的公钥的，因为数字签名是私钥加密，公钥解密。
B的公钥发送给A的时候依然会发生中间人攻击的问题，B第一步依然是将公钥发送给A，B怎么向A证明这个数据就是我的，它首先会去使用某种哈希算法对要传输的数据取得一个哈希值。
哈希函数的特点是输入不定长的值，总能够得到定长的值，且不可以逆向反推。也就是给你一个哈希值让你去反推原始数据是推断不出来的。
可以看到通过哈希取出来的值是一样的。不同哈希算法最后得出来的值长度是不一样的。
只要数据不变的出来的哈希值也是不变的，只要这个值变了，那么哈希值也是变的。
B会使用某种哈希函数对其取到哈希值，取得这个值之后叫做hash1，B的私钥加密的不是原始数据，它是对哈希值来做加密的，对哈希值加密之后就得到了数字签名，B就可以将原始数据以及它加密之后的哈希值，也即是使用私钥加密的哈希值传输给A，这个时候data依然是以明文的方式传输过来的。
数字签名并不是对数据来加密的，而是验证数据是否是B来给我发送的。
A收到data原始数据，以及B的私钥加密的哈希值，收到的是这两个东西。A要验证数据是否是B发送的，那到底是不是B发送的呢？在传输的过程当中有没有被别人改过呢？那么A要去考虑这些问题。
A有B的公钥，既然数字签名是使用B的私钥加密，那么可以使用B的公钥去解密，所以它会使用B的公钥去解密数字签名。A使用B的公钥能够解密出来，那么说明这个数据的确就是B发送过来的，
A会使用相同的哈希算法去对data取得一个哈希值，也就是传输之后的哈希值，然后和传输之前的哈希值对比hash2和hash1是否一样，求得的哈希值和你发送过来的hash值一样，那么就说明这个数据是真的。如果不一样就是假的，在传输过程当中被人修改了，这个就是所说的数字签名。
这个也很容易受到中间人攻击。
密钥对和主体没有关联：A和B是没有关联的，A是没有理由去相信B的。同时B的公钥和私钥是可以随时变化的，可以删除然后重新生成。
证书中心简称为CA。
B 首先生成自己的私钥，生成私钥之后会去使用自己的私钥去生成证书请求文件，然后发送给CA。
CA审核完之后给我们颁发证书，颁发的证书就是公钥，只不过这个证书上面有盖章，这个是CA给我们盖章的，这个就是数字签名，这个密钥对和主体就有联系了，因为证书私钥是绑定的，也是CA审核过的。所以B要说这个证书和密钥对不是你的都抵赖不了，因为有权威机构去证明了。
B将自己的公钥，也就是证书发送给A的时候，既然证书上有CA的数字签名，它会去使用CA的公钥来验证数字签名。也就是使用CA的公钥去解密然后去验证。
中间人攻击的问题就解决了，因为都信任ca。因为A会去CA验证B的证书的真伪。很容易避免中间人攻击。同时也解决密钥和主体之间没有联系的这样一个问题。
如果A也从CA获取了一个证书，B将证书发送给A的时候，A来验证B的数字签名。同理A将证书发送给B，B也要验证A发来的证书。这样A B就互相验证了，这样就实现了双向认证，这也就是双向TLS认证。
在网格内部pod通信其实都建立了mtls的通信。也就是双向TLS的通信。k8s组件之间也是mtls通信。
所以这里有两套CA，一套k8s的CA，还有一套是istio使用的CA。