本文主要给大家简单讲讲部署Istio实现双向TLS迁移讲析，相关专业术语大家可以上网查查或者找一些相关书籍补充一下，这里就不涉猎了，我们就直奔部署Istio实现双向TLS迁移讲析主题吧，希望可以给大家带来一些实际帮助。
成都创新互联提供高防服务器、云服务器、香港服务器、四川移动机房托管等
在Istio中，双向TLS是传输身份验证的完整堆栈解决方案，它为每个服务提供可跨集群的强大身份、保护服务到服务通信和最终用户到服务通信，以及提供密钥管理系统。本文阐述如何在不中断通信的情况下，把现存Istio服务的流量从明文升级为双向TLS。
使用场景
在部署了Istio的集群中，使用人员刚开始可能更关注功能性，服务之间的通信配置的都是明文传输，当功能逐渐完善，开始关注安全性，部署有sidecar的服务需要使用双向TLS进行安全传输，但服务不能中断，这时，一个可取的方式就是进行双向TLS的迁移。
下面通过实例演示如何进行双向TLS的迁移。
环境准备
• 已经部署好Istio的集群，没有启用双向TLS
• 创建三个命名空间，分别是 foo、bar 以及 legacy
• 在 foo、bar 中分别部署注入 Istio sidecar 的 httpbin 以及 sleep 应用，在legacy中部署未注入sidecar的sleep应用
检查部署情况
可以看到，从任意一个命名空间选一个sleep应用，发送http请求到httpbin.foo，都能请求成功。这个时候，使用的是明文传输。
检查系统中的认证策略和目标规则：
可以看到，系统中在foo、bar 以及 legacy命名空间下没有认证策略和目标规则。
下面开始通过配置服务端和客户端来升级传输过程：
向服务端注入以下策略：
上图策略中，模式为PERMISSIVE，这个模式让云服务器能够同时接收明文和双向TLS流量，具体使用哪种方式由实际配置决定。再次验证网络通信，可以看到所有请求都成功，目前使用的还是明文的方式。
通过设置下图所示DestinationRule，为服务端添加目的地规则：
这些规则生效后，客户端sleep.foo 和 sleep.bar 就会开始使用双向 TLS 和 httpbin.foo 进行通信了，而sleep.legacy因为没有注入sidecar，因此不受DestinationRule 配置影响，还是使用明文来和httpbin.foo通信。
通过发送请求验证上述分析，可以看到三个应用都访问成功：
通过上述方式，可以把不同的客户端和服务端之间流量都迁移到双向TLS。当系统中的流量都迁移完毕，并且希望所有应用之间都通过双向TLS进行安全传输，我们可以将应用间的传输锁定为双向TLS。具体操作方式如下：将配置的认证策略mtls的模式修改为STRICT，这样，服务端就只运行使用双向TLS这一种方式接收流量。
锁定之后，再发送请求验证通信，可以看到，sleep.legacy 的请求失败，这是因为sleep.legacy没有注入sidecar，无法进行双向TLS传输。
总结：通过上述演示，可以了解到，将服务通信从明文流量传输迁移到双向TLS传输的过程是十分方便的，可以根据服务的实际需求按需配置，不会对服务的正常通信产生任何影响。
部署Istio实现双向TLS迁移讲析就先给大家讲到这里，对于其它相关问题大家想要了解的可以持续关注我们的行业资讯。我们的板块内容每天都会捕捉一些行业新闻及专业知识分享给大家的。
