Securing a Civo K3s Cluster with Kuma Service Mesh(Baseline Implementation)

Cherry Ghosh — Fri, 09 Jan 2026 12:21:29 +0000

Introduction

Service meshes are often considered to be too heavy, complex, and not needed when working with small Kubernetes clusters. Users who have already tried to implement Istio on limited infrastructure have known this fact well.

This is a clean baseline implementation of the Kuma Service Mesh on a managed Civo K3s cluster, which focuses on zero-trust mTLS security and does not require application code changes. The layout forms a basis of advanced traffic and security control on later work. The K3s cluster was created using the Civo dashboard.The cluster itself is a mere infrastructure and all mesh capabilities are implemented inside Kubernetes.

Environment

Platform: Civo Kubernetes (K3s)
Cluster: 2-node managed cluster
Service Mesh: Kuma 2.13.0
Client Tools: kubectl, kumactl (via WSL)
Demo App: Podinfo

Step 1: Provisioning the Cluster on Civo

A standard K3s cluster was created using the Civo dashboard.
This cluster serves purely as infrastructure; all mesh functionality is deployed inside Kubernetes.

Screenshot: Civo Kubernetes cluster overview showing nodes and status.

Step 2: Installing the Kuma Control Plane

Kuma was installed using the official CLI, piping the generated manifest directly into Kubernetes:

kumactl install control-plane | kubectl apply -f -

After installation, the control plane was verified in the kuma-system namespace.

Screenshot: kubectl get pods -n kuma-system showing kuma-control-plane running.

Step 3: Onboarding Workloads with Sidecar Injection

A dedicated namespace was created and labeled to enable automatic sidecar injection:

kubectl create namespace kuma-demo
kubectl label namespace kuma-demo kuma.io/sidecar-injection=enabled

The Podinfo demo application was deployed and restarted to trigger Envoy sidecar injection.

kubectl apply -n kuma-demo -f https://raw.githubusercontent.com/stefanprodan/podinfo/master/kustomize/deployment.yaml
kubectl rollout restart deployment -n kuma-demo

Each pod now runs with two containers: the application and the Kuma sidecar proxy.

Screenshot: kubectl get pods -n kuma-demo showing 2/2 Ready.

Step 4: Enabling Zero-Trust mTLS

By default, Kuma runs in permissive mode. Mutual TLS was enabled at the mesh level using a built-in CA:

apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:
  name: default
spec:
  mtls:
    enabledBackend: ca-1
    backends:
      - name: ca-1
        type: builtin

kubectl apply -f mtls-policy.yaml

This enforces encrypted, authenticated communication between all services in the mesh.

Step 5: Verifying the Mesh

Workload registration was confirmed using:

kumactl get dataplanes

The Kuma Manager UI was accessed via port-forwarding:

kubectl port-forward svc/kuma-control-plane -n kuma-system 5681:5681

From the UI, the mesh status clearly shows mTLS enabled and data plane proxies online.

Screenshots:

Kuma Manager overview

Mesh detail page showing mTLS: builtin / ca-1

Observations

Kuma can easily be combined with lightweight K3s clusters.
There was no need to make any changes to application code.
Civo provides fast and predictable infrastructure that enables service mesh experimentation.
Mesh level security is fully operated at the Kubernetes level without any reference to the user interface of the cloud provider.

Conclusion

In under an hour, it is possible to upgrade an unsecured Kubernetes cluster into a zero-trust, mTLS-enforced service mesh with Kuma on Civo.

This combination provides a great balance between simplicity, performance and security to developers working on smallto medium K3s clusters.

DEV Community: Cherry Ghosh