We are happy to announce a new major release of Kuma, and a new major release of Kong Mesh built on Kuma! Kuma 1.4 ships with 25+ new features and countless improvements, particularly when it comes to performance. As previously announced at Kong Summit 2021, Kong Mesh ships we enterprise capabilities for large scale service mesh deployments, like RBAC, and native support for Windows VMs.

We strongly suggest to upgrade, in order to take advantage of the latest and greatest when it comes to service mesh.

Improvements in Kuma 1.4 and Mesh 1.5

• 🚀 Kong Mesh ships with native RBAC that works universally across Kubernetes and VMs.
• 🚀 Kong Mesh also ships with native support for Windows VMs, in addition to the existing 10+ distributions it already provides.
• 🚀 Performance is significantly improved, with ability to load 2x more data plane proxies, and less CPU consumption.
• 🚀 You can now disable zones as needed.
• 🚀 You can now select a specific zone in the “Kuma Service” dashboard and in the “Service to Service” dashboard.

For a complete list of features and updates, take a look at the full changelog.

RBAC

In Kong Mesh 1.5, the new RBAC feature is enabled by default and it works consistently across both Kubernetes and Universal environments, in both standalone and multi-zone deployments, across every cloud. By using this new feature we can better scale Kong Mesh operations across the organizations by restricting what our teams and their individual contributors can do on top of one or more virtual meshes. You can learn more about this feature in the official documentation.

RBAC introduces a few important concepts:

AccessRole

AccessRole is a resource that defines a role that can later be assigned for a user. This resource is global-scoped, which means it is not bound to a mesh. Below an example of an AccessRole:

type: AccessRole
name: role-1
rules:
- types: ["TrafficPermission", "TrafficRoute", "Mesh"] # list of types to which access is granted. If empty, then access is granted to all types
  names: ["res-1"] # list of allowed names of types to which access is granted. If empty, then access is granted to resources regardless of the name.
  mesh: default # Mesh within which the access to resources is granted. It can only be used with the Mesh-scoped resources.
  access: ["CREATE", "UPDATE", "DELETE", "GENERATE_DATAPLANE_TOKEN", "GENERATE_USER_TOKEN", "GENERATE_ZONE_CP_TOKEN"] # an action that is bound to a type.
  when: # a set of qualifiers to receive an access. Only one of them needs to be fulfilled to receive an access
  - sources: # a condition on sources section in connection policies (like TrafficRoute or Healtchecheck). If missing, then all sources are allowed
      match:
        kuma.io/service: web
    destinations: # a condition on destinations section in connection policies (like TrafficRoute or Healtchecheck). If missing, then all destinations are allowed
      match:
        kuma.io/service: backend
  - selectors: # a condition on selectors section in dataplane policies (like TrafficTrace or ProxyTemplate).
      match:
        kuma.io/service: web
  - dpToken: # a condition on generate dataplane token.
      tags:
      - name: kuma.io/service
        value: web

AccessRoleBinding

This resource binds an AccessRole to a User/Group. For example

type: AccessRoleBinding
name: binding-1
subjects: # a list of subjects that will be assigned roles
- type: User # type of the subject. Available values: ("User", "Group")
  name: john.doe@example.com # name of the subject.
- type: Group
  name: team-a
roles: # a list of roles that will be assigned to the list of subjects.
- role-1

User/Group

The “AccessRoles” can be bound to a specific “User” or “Group” of users. In Kubernetes, users are being identified by their login credentials provided via “kubectl login”, whereas in Universal they are identified by the underlying Kuma user token.

In the future, this creates the perfect foundation for adding OIDC/LDAP support to Kong Mesh as an additional way to authenticate users.

Performance Improvements

This release includes performance improvements that have been identified by our new performance suite which replicates a Kuma deployment at scale. This allows us to anticipate some performance issues that you may be experiencing in production and ship a fix as part of our continuous improvements to the product.

Particularly, we have reduced the likelihood of overwhelming the underlying Postgres database in universal mode, and we are making incremental improvements to the CPU and memory consumption of Kuma. These performance improvements are our top priority, so please reach out to the maintainers if you would like to report any issue running Kuma at scale.

Upgrading