Overview 🔗︎

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

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.

isito-mtls

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 CLI repo.

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:

    mesh-mtls

  • 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.

    mtls-set

    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.