By on November 13, 2019

Securing Kubernetes Applications in 5 Minutes with Service Mesh

We announced the release of Kuma – a modern, universal control plane for service mesh back in September 2019. Since then, a roaring wave of community feedback and contribution has flooded the project. And that’s a good thing, so thank you to everyone who has given their time to helping Kuma grow. One recurring feedback we got was that the community was excited to see a platform-agnostic service mesh. Unlike other control planes, Kuma natively runs across any platform, and it’s not limited in scope. With KubeCon NA right around the corner, let us explore one of the platforms that you can deploy Kuma.

Start Kubernetes and Marketplace Application

To start, you need a Kubernetes cluster with at least 4GB of memory. We’ve tested Kuma on Kubernetes v1.13.0 – v1.16.x, so use anything older than v1.13.0 with caution. In this tutorial, we’ll be using v1.15.4 on minikube, but feel free to run this in a cluster of your choice.

When running on Kubernetes, Kuma will store all of its state and configuration on the underlying Kubernetes API Server, therefore requiring no dependency to store the data.

With you’re Kubernetes cluster up and running, we can throw up a demo application built for Kuma. Deploy the marketplace application by running:

This will deploy our demo marketplace application split across 3 pods. The first pod is an Elasticsearch service that stores all the items in our marketplace. The second pod is a Redis service that stores reviews for each item. The third pod is our Node/Vue application that allows you to visually query the Elastic and Redis endpoints. Let’s check the pods are up and running by checking the kuma-demo namespace:

With the application running, port-forward the sample application to access the front-end UI at http://localhost:8080:

Now that you can visualize the application, play around with it! You should be able to search for all the items we sell on the marketplace along with some reviews. While this application works, it is lacking a few important features. First, the traffic between the services is not encrypted. Second, we have no observability on our application if something was to fail. And lastly, if we needed to change how services can communicate, it’s not easily achievable. So let’s quickly solve all three things using Kuma.

Download Kuma

To start, we need to download the latest version of Kuma. 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:

Install Kuma

With Kuma downloaded, let’s utilize kumactl to install Kuma on our cluster. The kumactl executable is a very important component in your journey with Kuma so be sure to read more about it here. Run the following command to install Kuma onto our Kubernetes cluster:

When deploying on Kubernetes, you are supposed to change the state of Kuma by leveraging Kuma’s CRDs. Therefore, we will now use kubectl to help us through the remaining demo. To start, let’s check the pods are up and running within the kuma-system namespace:

While running on Kubernetes, no external dependencies required, since it leverages the underlying K8s API server to store its configuration. However, as you can see above, a kuma-injector service will also start in order to automatically inject sidecar data-plane proxies without human intervention. Data-plane proxies are injected into namespaces that includes the following label:

Now that our control-plane and injector are running, let’s delete the existing kuma-demo pods so they restart. This will give the injector a chance to deploy those sidecar proxies among each pod.

Check the pods are up and running again with an additional container. The additional container is the Envoy sidecar proxy that Kuma is injecting into each pod.

Now if we now port-forward our marketplace application again, I challenge you to spot the difference.

A-ha! Couldn’t find a thing right? Well, that is because Kuma doesn’t require a change to your application’s code in order to be used. The only change is that Envoy now handles all the traffic between the services. Kuma implements a pragmatic approach that is very different from the first-generation control planes:

  • it runs with low operational overhead across all the organization
  • it supports every platform
  • it’s easy to use while relying on a solid networking foundation delivered by Envoy.

And we see it in action right here!

Powerful Policies

With the mesh up and running, let’s start tackling the three issues I raised about this application. 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 builtin 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. By default, mTLS is not enabled. You can enable Mutual TLS by updating the Mesh policy like so:

With mTLS enabled, traffic is restricted by default. Remember to apply a TrafficPermission policy to permit connections between Dataplanes. So if you try to access the application, you will no longer see any items or reviews because the traffic between Node and Elasticsearch or Redis is now blocked off. 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? With the same TrafficPermission policy, we can easily lock down our Redis service. Let’s give that a shot:

In this manifest, I’m changing the everything TrafficPermission policy to have a very specific source and destination. Now, only traffic from the kuma-demo-api service will be routed to the Elasticsearch service. Essentially, cutting the Redis service out of the application, giving us some time to find out who is targeting us and remove 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.