By on January 8, 2020

Deploying Service Mesh on Virtual Machines in 5 Minutes

Welcome to another hands-on Kuma guide! In the first guide, I walked you through securing an application using Kuma in a Kubernetes deployment. Since Kuma is platform-agnostic, I wanted to write a follow-up blog post on how to secure your application if you are not running in Kubernetes. This capability to run anywhere differentiates Kuma from many other service mesh solutions in the market.

To learn how Kuma works on universal mode, we’re going to cover three things today:

  1. Deploying the Kuma sample app on virtual machines using Vagrant
  2. Enabling mTLS to secure traffic between our applications’ components
  3. Using granular traffic permission policies to route traffic

For folks who followed along on our first blog post, this structure may look familiar.That is by intention. Deploying and configuring Kuma was designed since release to be easy regardless of where you deploy it.

So without further ado, let’s accomplish the three tasks listed above in a matter of minutes!

Install Dependencies and Sample Application

We’ll be using Vagrant to deploy our application and demonstrate Kuma’s capabilities in universal mode. Please follow Vagrant’s installation guide to have it set up correctly before proceeding with this guide. I’ll be using Vagrant 2.2.6. You can check using the Vagrant CLI command to verify the installation was successful. 

We need to download the latest version of Kuma next. You can find installation procedures for different platforms on our official documentation. The following guide is being created on macOS, so it will be using the Darwin image:

Next, let’s unbundle the files to get the following components:

Lastly, go into the ./bin directory where the kuma components will be:

The kumactl application is a CLI client for the underlying HTTP API of Kuma. Therefore, you can access the state of Kuma by leveraging the API directly. You can configure kumactl to point to any remote kuma-cp instance. This is the reason we wanted to have Kuma downloaded on our local machine. Add this directory to your path so you can call kumactl from anywhere:

Now, to verify it is working, check that Kuma’s version correlates with the package you downloaded by using kumactl:

Download Kuma Marketplace 

We built a sample application that will help illustrate how Kuma works. The sample application is an online marketplace where you can query fashion items and check the reviews left by users. You can find it on our GitHub repository and clone it onto your local machine:

Navigate into the Vagrant directory in the Kuma demo to find the following files:

We’ve built out a Vagrantfile that will automatically deploy the sample application across five virtual machines (VMs):

  1. Kuma-control-plane: Machine that houses the Kuma control plane 
  2. Redis: Redis database that holds the reviews for all our items
  3. Elastic: Elasticsearch database that holds all our items’ metadata
  4. Back End: Node API that exposes an endpoint for front end to query databases
  5. Front End: Vue application that allows users to visualize items and reviews that they search for

If you wish to inspect the scripts used to deploy each component of our application, feel free to dig into their respective directories. 

Deploy Kuma Marketplace 

With the Vagrantfile already built out, all you have to run is the following command to get the application up and running:

This step may take a while depending on your machine and internet speed because we are spinning up five virtual machines asynchronously. This would be a great time to inspect the files and scripts included to get a better understanding of each component. 

Once the vagrant up command is complete, run vagrant status to check that we have the five machines listed above:

Lastly, before we can start shopping on the Kuma marketplace, port-forward the frontend machine. Run:

Now you can access the application if you go to http://localhost:8080. All the traffic between the machines are routed through Kuma’s data plane.

Powerful Policies

With the mesh up and running, let’s start improving our application by fixing a few issues it has. First, we have no encryption between our services, which leaves us vulnerable to attack. Kuma can easily fix this by utilizing the mutual TLS policy. This policy enables automatic encrypted mTLS traffic for all the services in a mesh. Kuma ships with a built-in CA (Certificate Authority), which is initialized with an auto-generated root certificate. The root certificate is unique for every mesh and it used to sign identity certificates for every data-plane. You can provide your own CA if you wish to do so, thanks to Jakub’s new feature in the latest 0.3.1 release.

By default, mTLS is not enabled. You can enable mTLS by updating the mesh policy using kumactl. However, since kumactl is on our local machine and the Kuma control-plane is in a virtual machine, we need to configure kumactl to point to a remote kuma-cp instance. Configure your local kumactl to point to our Vagrant machine by running:

To check if kumactl was properly configured, use the kumactl inspect dataplanes  to list the components in our demo application:

With kumactl configured properly, we can finally update the mesh resource and turn on mTLS in our mesh:

With mTLS enabled, traffic is restricted by default. Remember to apply a Traffic Permission policy to permit connections between data planes. If you try to access the application right now at http://localhost:8080, the application will no longer work, since traffic is encrypted and you do not have any permissions. Traffic Permissions allow you to determine security rules for services that consume other services via their Tags. It is a very useful policy to increase security in the mesh and compliance in the organization. You can determine what source services are allowed to consume specific destination services like so:

In this case, our rule states that any source service has permission to route traffic to any destination service. So, if we now access our marketplace at http://localhost:8080, the demo application will look like it’s normal again. However, now all the traffic between Elasticsearch, Node and Redis is encrypted! 

But wait! Hypothetically, some other marketplace was disgruntled by our awesome webpage and starts spamming all our product with fake reviews. What could we do? First, we have to delete the existing permission that allows traffic between all services:

With two granular Traffic Permission policies, we can easily lock down our Redis service:


In these two manifests, I’m changing the original Traffic Permission policy to have a very specific source and destination. The first one will give the frontend and backend permission to send traffic. The second will allow backend to communicate with elastic to query items. Without granting the redis service any permissions, the rest of the application can no longer communicate with it. Traffic Permission helps us place redis in solitary confinement until we find out who is targeting us with falsified reviews. 

That’s all! This was a really quick run-through, so make sure you check out Kuma’s official webpage or repository to find out about more features. You can also join our Slack channel to chat with us live and meet the community! Lastly, sign up for the Kuma newsletter below to stay up to date as we push out more features that will make this the best service mesh solution for you.