OpenShift 4 之Istio-Tutorial (8) 在服务之间配置Mutual TLS双向传输安全
本系列OpenShift Servic Mesh教程是基于Red Hat官方公开发行的《Introducing Istio Service Mesh for Micoservices》出版物，我将所有操作在OpenShift 4.2.x环境中进行了验证。喜欢读英文或者需要了解更多和场景相关知识点的小伙伴可以通过上面的链接下载该书慢慢阅读。
在Service Mesh中，两个微服务之间双向传输安全是由Sidecar完成的。如下图，运行微服务的容器和Sidecar容器之间是网络互信的，因此是通过通过一般网络连接的，而Service A和Service B之间的网络安全传输是通过在与它们相对应的Sidecar之间的Mutual TLS实现的。本文演示如何为访问Preference微服务配置双向传输安全Mutual TLS。
在开始配置前需要根据《OpenShift 4 之Istio-Tutorial (2) 部署三个微服务》准备微服务环境即可。
- 先在istio-tutorial项目中部署一个pod，以后会使用其上的curl功能。
$ oc apply -f curl/Deployment.yaml -n istio-tutorial
- 在第一个窗口执行以下脚本，分别进入curl和customer的pod中，然后访问perference微服务的Service的访问地址-http://preference:8080 。
$ ./scripts/run_mTLS.sh
Executing curl in curl pod
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 61 100 61 0 0 4692 0 --:--:-- --:--:-- --:--:-- 0preference => recommendation v1 from '67976848-4l4s7': 4602
----------------------------------------------------------------------------
Executing curl in customer pod
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0preference => recommendation v1 from '67976848-4l4s7': 4603
100 61 100 61 0 0 10166 0 --:--:-- --:--:-- --:--:-- 10166
----------------------------------------------------------------------------
- 在Kiali控制台中可以看到有2个源向preference发送请求。
- 在第二个窗口执行命令创建Policy，为preference指定Mutual TLS。
文件istiofiles/authentication-enable-tls.yml为preference目标配置了一个Policy，并设置了mtls mode为STRICT，即preference接收的必须的是TLS请求。
apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
name: "preference-mutualtls"
spec:
targets:
- name: preference
peers:
- mtls:
mode: STRICT
执行命令创建policy。
$ oc apply -f istiofiles/authentication-enable-tls.yml
policy.authentication.istio.io/preference-mutualtls created
$ oc get policy
NAME AGE
preference-mutualtls 21s
- 此时第一个窗口的输出已经发生变化，从curl和customer的pod发出请求都由于被preference拒绝而失败了。
Executing curl in curl pod
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (56) Recv failure: Connection reset by peer
command terminated with exit code 56
----------------------------------------------------------------------------
Executing curl in customer pod
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 95 100 95 0 0 47500 0 --:--:-- --:--:-- --:--:-- 47500upstream connect error or disconnect/reset before headers. reset reason: connection termination
----------------------------------------------------------------------------
- 在Kiali控制台中可以看到100%红色的失败状态。
- 第二个窗口文件查看istiofiles/destination-rule-tls.yml文件，它创建一个DestinationRule对象，并在其中指定通过TLS的ISTIO_MUTUAL方式（在同一istio范围的客户端会使用istio提供的证书）访问preference。
apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
name: "preference-destination-rule"
spec:
host: "preference"
trafficPolicy:
tls:
mode: ISTIO_MUTUAL
执行命令创建DestinationRule对象：
$ oc apply -f istiofiles/destination-rule-tls.yml
- 在第一个窗口继续查看输出，确认现在已经可以从customer向preference正常访问，不过从curl pod发的请求还不能访问preference，这是由于curl pod不是以Service Mesh运行的，即它是单独运行的pod，其中没有Sidecar容器来自动完成mTLS过程。
Executing curl in curl pod
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (56) Recv failure: Connection reset by peer
command terminated with exit code 56
----------------------------------------------------------------------------
Executing curl in customer pod
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0preference => recommendation v1 from '67976848-4l4s7': 5858
100 61 100 61 0 0 12200 0 --:--:-- --:--:-- --:--:-- 12200
----------------------------------------------------------------------------
- 在Kiali控制台中也可以看到从customer已经可以正常访问preference了。在Kiali的Graph界面中可选中Display的Security选项，此时可以看到从customer到preference的访问连线上有个一“锁”的图标，这代表是通过mTLS访问的。
- 为了能让preference也能接收到来自curl pod发过来的请求（由于这个pod不是以istio体系运行的，所以只能发送非证书加密的plaintext明文），需要用istiofiles/authentication-enable-tls-permissive.yml文件更新preference的Policy为PERMISSIVE模式，让其即可接收mTLS请求，还可接收plaintext明文请求。
文件istiofiles/authentication-enable-tls-permissive.yml：
apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
name: "preference-mutualtls"
spec:
targets:
- name: preference
peers:
- mtls:
mode: PERMISSIVE
执行命令更新Policy对象：
$ oc apply -f istiofiles/authentication-enable-tls-permissive.yml
- 在第一个窗口继续查看输出，确认现在已经可以从curl和customer向preference正常访问了。
Executing curl in customer pod
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0preference => recommendation v1 from '67976848-4l4s7': 6937
100 61 100 61 0 0 8714 0 --:--:-- --:--:-- --:--:-- 8714
----------------------------------------------------------------------------
Executing curl in curl pod
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0preference => recommendation v1 from '67976848-4l4s7': 6938
100 61 100 61 0 0 4692 0 --:--:-- --:--:-- --:--:-- 4692
----------------------------------------------------------------------------
- 在Kiali控制台中也可以看到从curl和customer已经可以正常访问preference了。其中一个使用过“有锁”的mTLS访问，另一个是“无锁”的PlainText明文访问的。
- 执行命令，恢复环境。
$ oc delete -f istiofiles/authentication-enable-tls.yml
$ oc delete -f istiofiles/destination-rule-tls.yml