OpenShift Istio-Tutorial (8) 4 Mutual TLS configuration of bidirectional transmission between the security services

This series OpenShift Servic Mesh tutorial is based on Red Hat official public offering " Introducing Istio Service Mesh for Micoservices " publication, I will verify all operations carried out in OpenShift 4.2.x environment. Like to read or need to learn more English and knowledge of the relevant scene small partners can download the book by reading the above slowly.

In the Service Mesh, the two-way transmission security between two micro service is done by the Sidecar. Below, the micro-operation services between the container and the container is Sidecar trust network, so by connecting through a general network, the secure network transmission between a Service A and Service B between them through the corresponding Sidecar the Mutual TLS implementation. This article demonstrates how to configure the two-way transmission Security Mutual TLS for accessing micro Preference Service.Here Insert Picture Description

Needs "before the start of the configuration according to (2) the deployment of three micro-services OpenShift Istio-Tutorial 4 of " Preparing micro-services environment can be.

  1. First deployed in a pod istio-tutorial project, the future will use curl functions on it.
$ oc apply -f curl/Deployment.yaml -n istio-tutorial
  1. Execute the following script in the first window, respectively, into the pod curl and the customer, and then access perference micro services Service access address -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
----------------------------------------------------------------------------
  1. In Kiali console can be seen to have two sources preference transmission request.
    Here Insert Picture Description
  2. 在第二个窗口执行命令创建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
  1. 此时第一个窗口的输出已经发生变化,从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
----------------------------------------------------------------------------
  1. 在Kiali控制台中可以看到100%红色的失败状态。
    Here Insert Picture Description
  2. 第二个窗口文件查看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
  1. 在第一个窗口继续查看输出,确认现在已经可以从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
----------------------------------------------------------------------------
  1. 在Kiali控制台中也可以看到从customer已经可以正常访问preference了。在Kiali的Graph界面中可选中Display的Security选项,此时可以看到从customer到preference的访问连线上有个一“锁”的图标,这代表是通过mTLS访问的。
    Here Insert Picture Description
  2. In order to allow preference can receive the request from the hair curl over the pod (pod is not due to the istio system operation, it can send the non-encrypted plaintext plaintext certificate), need istiofiles / authentication-enable-tls- permissive. yml file update preference to the Policy PERMISSIVE mode, can receive mTLS allowed request, the request may also receive plaintext plaintext.
    File 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

Run Update Policy objects:

$ oc apply -f istiofiles/authentication-enable-tls-permissive.yml
  1. Continue to view the output in the first window, we can now confirm that normal access from the curl and the preference of the customer.
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
----------------------------------------------------------------------------
  1. In Kiali console can also be seen already can access and customer preference from curl up. One used the "lock" of mTLS access, and the other is "no lock" PlainText plaintext access.
    Here Insert Picture Description
  2. Run, restore the environment.
$ oc delete -f istiofiles/authentication-enable-tls.yml
$ oc delete -f istiofiles/destination-rule-tls.yml
Published 54 original articles · won praise 0 · Views 1053

Guess you like

Origin blog.csdn.net/weixin_43902588/article/details/104027122