Zero Trust security with Kuma Service Mesh

Zero Trust isn't a buzzword, in the era of the hybrid cloud and the multicloud most companies are changing their approach to security. The Zero Trust model drastically changes the way to secure IT systems, in fact, it assumes that everyone could be an attacker, so every access needs to be authenticated and authorized.
In Kubernetes, every workload can communicate with one another without any restrictions, so Kubernetes doesn't guarantee Zero Trust Security and if you want to achieve it, you need to build or use something on top of the Kubernetes network. A Service Mesh can help you to resolve this problem by managing identity, introducing authorization through mTLS, and defining traffic policies.

Kuma

Kuma is a mesh control plane for both K8s and VMs with native multi-cloud and multi-cluster connectivity. It was developed originally by Kong Inc then donated to the CNCF (Sandbox project), and now is at version 2.0.
How we can implement Zero trust security with Kuma?
Kuma allows you to manage and issue certificates in a declarative way, you can choose to use the built-in CA or to provide your existing one. In this way, every service in the mesh will have a certificate (identity) and all the connections will be authorized through mTLS. Below you can see how to enable the mTLS policy.

apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:
  name: default
spec:
  mtls:
    enabledBackend: ca-1
    backends:
      - name: ca-1
        type: builtin
        dpCert:
          rotation:
            expiration: 1d
        conf:
          caCert:
            RSAbits: 2048
            expiration: 10y

Ok, now all the services have an identity but, by default, all the services can communicate with each other, because of an existing Traffic Permission Policy.

apiVersion: kuma.io/v1alpha1
kind: TrafficPermission
mesh: default
metadata:
  name: allow-all-traffic
spec:
  sources:
    - match:
        kuma.io/service: '*'
  destinations:
    - match:
        kuma.io/service: '*'

Through this policy, all the traffic is allowed within the Mesh. If you want to enforce Zero Trust, allowing only some specific paths, you should define your own Traffic Policies. An example below:

apiVersion: kuma.io/v1alpha1
kind: TrafficPermission
mesh: default
metadata:
  name: demoapp-to-redis
spec:
  sources:
    - match:
        kuma.io/service: demo-app_kuma-demo_svc_5000
  destinations:
    - match:
        kuma.io/service: redis_kuma-demo_svc_6379

What are the benefits of using Kuma to implement Zero Trust security?

Kuma allows the developer to focus only on the development of the business features, ignoring all the security aspects. In this way, you prevent every team develops its security framework, reducing the cognitive load of every developer and, in a heterogeneous ecosystem, a huge code fragmentation.
Kuma also reduces the manual effort to rotate the certificates when they expire and to provide a certificate for every service of your applications. In fact, when you define the mTLS policy, every service that joins the Mesh will be provided with its own certificate automatically.