Integrating Kuma with Styra DAS

In this blog, you will learn how to install Kuma on a Kubernetes cluster and add ingress policies in Styra DAS to integrate Kuma with Styra DAS.

What is Kuma?

Kuma is a platform-agnostic open-source control plane for service mesh and microservices management, with support for Kubernetes, VM, and bare-metal environments.

Kuma addresses the limitations of first-generation service mesh technologies by enabling seamless management of any service on the network, including L4 and L7 traffic, as well as microservices and APIs. Its fast data plane and advanced control plane make it significantly easier to use and adopt across every team.

Kuma makes the underlying network safe, reliable, and observable without having to change any code. The combination of its fast data plane and advanced control plane allows users to easily set permissions, expose metrics and set routing rules with just a few commands by either using native Kubernetes CRDs or a RESTful API.

Kuma is:

• Universal and Kubernetes-native: Platform-agnostic, can run and operate anywhere.
• Standalone and multi-zone: Supports multiple clouds, regions, and Kubernetes clusters with native DNS service discovery and ingress capability.
• Multi-mesh: Supports multiple individual meshes with one control plane, lowering the operational costs of supporting the entire organization.
• Attribute-based policies: This Lets you apply fine-grained service and traffic policies with any arbitrary tag selector for sources and destinations.
• Envoy-based: Powered by Envoy sidecar proxies, without exposing the complexity of Envoy itself.
• Horizontally scalable
• Enterprise-ready: Supports mission-critical enterprise use cases that require uptime and stability.

There are two main components of Kuma that are very important to understand:

• Control Plane: Kuma is first and foremost a control plane that will accept user input (you are the user) in order to create and configure Policies like Service Meshes, and in order to add services and configure their behavior within the Meshes you have created.
• Data Plane Proxy: Kuma also bundles a data plane proxy implementation based on top of Envoy. An instance of the data plane proxy runs alongside every instance of our services (or on every Kubernetes Pod as a sidecar container). This instance processes both incoming and outgoing requests for the service.

This tutorial shows how Envoy’s external authorization filter in Kuma can be used with OPA as an authorization service to enforce security policies over API requests received by Kuma.

Kuma Architecture:

The DAS Kuma system type helps you manage the ingress and egress network traffic permitted within your OPA-integrated Kuma Service Mesh.

Prerequisites:

1. Kuma 1.3.0 or later to be installed on Kubernetes 1.14 or later.
2. Styra DAS Account, you can sign up for a free account here.

Steps to install Kuma:

1. Download Kuma:

You can run the following script to automatically detect the operating system and download Kuma:

curl -L https://kuma.io/installer.sh | sh -

2. Run Kuma

Once downloaded, you will find the contents of Kuma in the kuma-1.4.1 folder.

cd kuma-1.4.1/bin

Finally, we can install and run Kuma in either standalone or multi-zone mode:

./kumactl install control-plane | kubectl apply -f -

create link in /usr/local/bin/ by executing:

ln -s ./kumactl /usr/local/bin/kumactl

check the status by running:

kubectl get pod -n kuma-system

Run the command below and check the Kuma dashboard using your IP address with port 5681/GUI.

./kuma-cp run

Installation steps to create a Kuma system, install Styra on Kuma, enforce and validate the ingress policy:

1. Create a Kuma System:​

To demonstrate the enforcement of ingress and egress policies for a sample application, you can start by creating a new Styra Kuma system. Systems are displayed on the left side of the navigation panel. To add a new Kuma system, click the + next to SYSTEMS on the left side of the navigation panel.

2. Install the Kuma Example Application:

To install Styra on Kuma, you must copy and paste all the three installation commands from SYSTEMS >> Settings >> Install for your Kuma system into your terminal. This configures the Kuma Proxy template and Kuma controller. Enable Kuma sidecar injection on the default namespace and deploy Styra Local Plane (SLP). For the custom namespace, make sure Kuma sidecar injection is enabled and deploy SLP accordingly.

The Kuma system QuickStart provides the link to install an example application. It consists of the following components:

example-app is a simple HTTP web server that allows employees of a hypothetical organization to obtain salary details via the API /finance/salary. It also exposes HR information via the API /hr/dashboard.

client-load is a simple shell script that generates pre-configured HTTP GET requests to test the behavior of the deployed policy.

Check that the app loaded correctly using the below command:

Kubectl get pods:

3. Enforce the Ingress Policy:

By default, all policies allow traffic to the service with the Kuma data plane sidecar container. Click on the Decisions tab to verify all the Allowed decisions from the newly created Kuma system.

The Kuma system Quick Start provides a link to replace the sample ingress policy. With this ingress policy published, example-app can receive ingress traffic only on the allowed list of endpoint /finance/salary. Switch to the Decisions tab and verify traffic to path /hr/dashboard and /admin are Denied.

package policy.ingress 
default allow = false
# allow /finance/salary/{user} ingress
allow {
  some username
  input.attributes.request.http.method == "GET"
  input.parsed_path = ["finance", "salary", username]
}

Before you deploy it, see if it’s doing what you want. Click on validate. The Validate button will tell you what percentage of past decisions will be changed by your new policy. Now publish the policy and check the decisions.

Modify your policy to allow inbound requests on the “/hr/dashboard” endpoint in the example app.

package policy.ingress
default allow = false# allow /finance/salary/{user} ingress
allow {
  some username
  input.attributes.request.http.method == "GET"
  input.parsed_path = ["finance", "salary", username]
}# allow /hr/dashboard ingress
allow {
  input.attributes.request.http.method == "GET"
  input.parsed_path = ["hr", "dashboard"]
}

Publish your modified policy and check the changed decisions. See that your new rule would allow ingress requests to host “/hr/dashboard” as well.

Congratulations!

Now, you have learned the following about Kuma with OPA and Styra:

Summary:

Added Kuma system on Styra DAS.

Configured Kuma Proxy template and Kuma controller. Enabled Kuma sidecar injection on the default namespace and deployed Styra Local Plane (SLP).

Deployed sample application and applied ingress rules.

Validated and published the ingress policies.

You can use StyraDAS to write policies, distribute policies to OPA, and manage the decisions made by OPA.

References :

1. OPA Documentation
2. Styra Academy