Kuma 1.4 and Kong Mesh 1.5 Released With RBAC, Windows Support, 2x Performance and 25+ New Features
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:
AccessRoleBinding
This resource binds an AccessRole to a User/Group. For example
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.