Microservices architectures are becoming the de facto way developers are thinking about how their applications are constructed. But security remains a top concern to most organizations.  Therefore, it is important to understand the intersection of security and microservices. While not guaranteeing your application will be secure, we can look at some of the capabilities that can be leveraged to address security concerns with microservices.  

OpenShift Service Mesh uses Istio’s three main principles to solve this new paradigm of security. The first one is Security by default, meaning that users won’t need to change any single line of code in order to use its security features. Secondly, Defense in depth where users can integrate their own security services with the service mesh existent ones (for instance, combining it with Kubernetes RBAC system). And last but not least, Zero-trust network that states that Service Mesh won’t consider security measures installed in the underneath platform. Strong identities, mTLS and RBAC are the most common features. Let’s explore the mTLS and how Kiali can help with that.

Start with mTLS

The goal of this section is to implement mTLS communications between all the services in the travel-agency namespace (but not to travel-portal). Before getting down to details, let’s understand what is mTLS. 

mTLS is the short name for Mutual TLS. mTLS is a protocol that applies the TLS authentication protocol in both directions: client to server and server to client. It is a popular authentication protocol for Machine-to-Machine communications where it is important not only to secure that the service is legit but also that the client is who says it is.

In order to achieve our goal, it is necessary to manage two different Istio Objects: the Destination Rule and the Policy. Let’s first add the DestinationRule object that will enforce all the workloads of the namespace to start connections with only mTLS.

In the overview page, Kiali shows the first hint of the mTLS status for each project available. As you can see in the ‘travel-agency’ namespace, there is a hollow lock icon next to the name telling that ‘mTLS partially enabled’. This means that either the security in that namespace is not properly enabled (this case) or there are communications without security enabled.

In addition, Kiali shows anomalies in health of both namespaces. This makes us think that there is an error on the last DestinationRule added. Let’s see what Kiali validations say regarding the validity of that Istio Object.

The screen right above shows the DestinationRule definition added just before through the Kiali editor. In this section, besides the fact of browsing, editing and deleting all kinds of Service Mesh objects, Kiali shows the result of the validity analysis of those objects. (All the validations provided by Kiali can be found here.)

In this example you can see that this DestinationRule has an error on the mode field saying “Policy enabling namespace-wide mTLS is missing”. This means that the service mesh needs a Policy enforcing all the services in travel-agency namespace to allow only mTLS connections. As a result of this error, line 19 is highlighted in red.

After adding the Policy, Kiali remove the error validation from the Policy:

At this point, mTLS is enabled for that namespace. But what if we’re a little paranoid and we want to make sure? Kiali has a useful security layer in the graph where it shows which connections are using mTLS, and at a glance, I can confirm that mTLS is enabled.

On one hand, as promised, the requests responded with 5xx errors are gone because the error has been fixed adding the Policy. On the other hand, you can see that each edge of the graph has now a lock icon right next to it. This means that there is some or all of the traffic using mTLS. On the side panel, Kiali shows the percentage of traffic using mTLS, ranging from 0 to 100%. At the beginning of the transition from non-mTLS to mTLS you will see numbers lower than 100%. As the traffic between services starts flowing, this number should be 100%. 

Going back to the overview page, you can see that the lock next to the travel-agency is full. Meaning that all the traffic within is configured to be mTLS.

One step is now complete

For most customers, application security is comprised of a number of steps, and mTLS is only one of those steps.  However, when moving to microservices and using a service mesh, being aware of the secure communication method available can help you plug one potential security hole.  The visualization of the security status provided by Kiali is one way you can quickly identify known holes as you work toward your application security goals.