Mutual TLS

Overview 🔗︎

Istio offers mutual TLS as a solution for service-to-service authentication.

Note: For FIPS-compliant TLS settings, see FIPS-compliant service mesh

Istio uses the sidecar pattern, meaning that each application container has a sidecar Envoy proxy container running beside it in the same pod.

1. When a service receives or sends network traffic, the traffic always goes through the Envoy proxies first.
2. When mTLS is enabled between two services, the client side and server side Envoy proxies verify each other’s identities before sending requests.
3. If the verification is successful, then the client-side proxy encrypts the traffic, and sends it to the server-side proxy.
4. The server-side proxy decrypts the traffic and forwards it locally to the actual destination service.

In Backyards, you can manage mTLS settings between services with the CLI or on the UI, mesh-wide, namespace-wide, and on the service-specific level.

Using the Backyards CLI 🔗︎

The following procedures show how you can change the mTLS settings. These are just examples to get you started, you can check the full list of mTLS commands in the Backyards docs.

Mesh-wide mTLS settings 🔗︎

1. Change the mesh-wide setting to PERMISSIVE with the following command:

   $ backyards mtls allow mesh
   INFO[0001] switched global mTLS to PERMISSIVE successfully
   

2. Then, verify that the setting is present:

   $ backyards mtls get mesh
   mTLS rule for /mesh
   Policy    Targets  MtlsMode
   /default  []       PERMISSIVE
   

Namespace-wide and service-specific mTLS settings 🔗︎

1. Create a STRICT Policy for the backyards-demo namespace.

   Note that after the command has been run successfully, the output returns the Policy which applies to the namespace.

   $ backyards mtls require backyards-demo
   INFO[0001] policy peers for backyards-demo/ set successfully
   mTLS rule for backyards-demo/
   Policy                  Targets  MtlsMode
   backyards-demo/default  []       STRICT
   

2. Create a PERMISSIVE Policy for the 8080 port of the bookings service in the backyards-demo namespace:

   $ backyards mtls allow backyards-demo/bookings:8080
   INFO[0001] policy peers for backyards-demo/bookings set successfully
   mTLS rule for backyards-demo/bookings
   Policy                         Targets           MtlsMode
   backyards-demo/bookings-r2xux  [bookings(8080)]  PERMISSIVE
   

3. Remove the Policy you’ve just set with the following command:

   $ backyards mtls unset backyards-demo/bookings:8080
   INFO[0001] policy peers for backyards-demo/bookings unset successfully
   mTLS rule for backyards-demo/bookings
   Policy                  Targets  MtlsMode
   backyards-demo/default  []       STRICT
   

   Note that when the service-specific Policy is removed for the bookings service, the namespace-wide Policy will be applied to the service.

4. Remove the Policy from the backyards-demo namespace as well:

   $ backyards mtls unset backyards-demo
   INFO[0001] policy peers for backyards-demo/ unset successfully
   mTLS rule for backyards-demo/
   Policy    Targets  MtlsMode
   /default  []       PERMISSIVE
   

   Note that when the namespace-wide Policy is removed from the backyards-demo namespace, the mesh-wide MeshPolicy will be applied to the namespace.

Using the Backyards UI 🔗︎

• You can change the mesh-wide mTLS settings on the Overview page:

  

• To create, edit, view, or remove namespace-wide and service-specific mTLS settings, open the Details panel of the namespace or service, then click on the Security tab.

  

  When a load is sent to the demo application, you can easily verify whether the traffic between your services is actually encrypted or not by glancing at the security edge labels. Either red open locks or green closed ones will appear around the services in the UI, indicating that encrypted or non-encrypted data has been sent between the services.