Istio 安全管理 加密证书中心

1 tls认证

2 设置ACL 允许哪些客户端可以访问 哪些客户端不能访问

3 istio里面的认证

加密是可以分为三种类型

  • 对称加密(加密和解密用的是同一个密钥)
  • 非对称加密
  • 哈希函数

对称加密

Istio 安全管理 加密证书中心_第1张图片

A要发送数据传送给B,那么A要使用一个密钥,里面写的是密码,要使用密钥对这个数据进行加密。

密码给到B那么B是打不开的,因为这个数据是被加密的,这个密码即使被别人截获了也没用的,对于B来说也是打不开的。A要想办法去告诉B说加密密码是haha001。

现在A不知道如何将密码告诉给B,所以这是一个问题。

加密和解密使用相同的密钥    优点:加密数据的速度比较快(适合加密大数据)    缺点:密钥不知该如何告诉对方(如果密钥传递给对方那么很容易被截获了)

Istio 安全管理 加密证书中心_第2张图片

非对称加密有两个密钥:

  • 公钥:可以公开的(谁都可以去获取的,安全性没有那么强而已)
  • 私钥:保存好,不可让别人获取
非对称加密的两个作用:
  • 数据加密:公钥加密,私钥解密
  • 数字签名:私钥加密,公钥解密

 A要发送数据给B,那么A要获取B的公钥,也就是A有了B的公钥。有了公钥之后会去加密需要传输的数据,完成之后将密钥发送给B,这个过程是不怕被别人截获的。截获了必须使用B的私钥去解密,所以私钥被保护好,不在其他人手上。

截获了因为没有私钥,这个时候数据传输到了B,那么B使用私钥去解密就行了。

可以看到对称加密时候加密大数据,非对称加密算法不适合加密大数据,所以可以将非对称加密算法和对称加密算法整合在一块去使用。

对称和非对称结合使用

Istio 安全管理 加密证书中心_第3张图片

 A使用对称算法加密了数据发送给B,这个时候B是不知道如何解密,因为A不知道如何将对称算法传输给B。

整合了非对称加密算法就容易多了,首先B会将自己的公钥发送给A,A会使用B的公钥加密对称算法的密钥,注意不是加密原始数据。

加密了对称算法的密钥之后,记住是使用B的公钥加密的,然后再传输给B,这个传输过程当中是安全的,被别人截获了也没用,被别人截获了之后也解不开,因为使用B的私钥才可以解开。

B收到使用自己公钥加密的数据之后,然后使用私钥对其解密,之后就得到了对称加密算法的密钥。最后就可以去解密对称加密算法的密钥了。

注意:这里使用B的公钥加密的是对称算法的密钥,而不是加密的原始数据。

 上面都有一个前提是B将公钥发送给A,A就真的以为是B的公钥。

中间人攻击 


Istio 安全管理 加密证书中心_第4张图片

B的公钥要传送给A的时候,这一步就被C给截获了,对于C来说也有自己的公钥和私钥的。C将自己的公钥传递给A,这叫伪装。它伪装为B的公钥。其实也就是被中间人调包了。

现在A是不明真相的群众不知道真假,用被调包的公钥去加密对称算法的密钥。在传输给B的过程当中又被截获了。之后C使用自己的私钥就完全可以解开这里面的数据。以为C截获了B的公钥,然后又使用B的公钥加密一份数据给B,这样就不存在解不开的情况。

上面就是所谓的中间人攻击。(1)泄露了数据,可以随意去看A和B之间的数据了。(2)c也可能会去修改其中的数据。

上面出现问题的环节就在第一步出现问题了。因为A就是不明真相的吃瓜群众。不能说别人发送给你,你就相信,发送给你B的公钥你就信任这个是B的公钥吗?这里是容易受到中间人攻击的。

这里就需要证书中心了。

 

数字签名


Istio 安全管理 加密证书中心_第5张图片

你去签合同,怎么证明才是你签名的合同呢?那就需要手印了。

所谓的数字签名就是给你发数据的时候给你按了一个手印,证明这个数据就是我的,这是我发送的,上面有我的手印。

数据签名就是用来验证数据的真伪,不去做数据的加密。

B要发送数据给A,要发送给A那么得要向A去证明数据就是B发送的。这个时候A依然是需要B的公钥的,因为数字签名是私钥加密,公钥解密。

B的公钥发送给A的时候依然会发生中间人攻击的问题,B第一步依然是将公钥发送给A,B怎么向A证明这个数据就是我的,它首先会去使用某种哈希算法对要传输的数据取得一个哈希值。

哈希函数的特点是输入不定长的值,总能够得到定长的值,且不可以逆向反推。也就是给你一个哈希值让你去反推原始数据是推断不出来的。

Istio 安全管理 加密证书中心_第6张图片

可以看到通过哈希取出来的值是一样的。不同哈希算法最后得出来的值长度是不一样的。

只要数据不变的出来的哈希值也是不变的,只要这个值变了,那么哈希值也是变的。

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的公钥和私钥是可以随时变化的,可以删除然后重新生成。

 

证书中心

Istio 安全管理 加密证书中心_第7张图片

证书中心简称为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。

 

你可能感兴趣的:(Service,Mesh,Istio,istio)