Add support for AWS Certificate Manager Private CA
Inspect API support for Open Policy Agent
Add license values to Mesh reports
Bump github.com/aws/aws-sdk-go from 1.40.56 to 1.43.29
Bump github.com/hashicorp/vault/api from 1.3.1 to 1.5.0
Bump github.com/open-policy-agent/opa from 0.37.1 to 0.38.1
chore(deps): Bump github.com/open-policy-agent/opa-envoy-plugin from 0.37.1-envoy to 0.38.1-envoy-3
controlPlane.resources is now on object instead of a string. Any existing value should be adapted accordingly.
Zone egress and ExternalService
When an ExternalService has the tag kuma.io/zone and ZoneEgress is enabled then the request flow will be different after upgrading Kuma to the newest version.
Previously, the request to the ExternalService goes through the ZoneEgress in the current zone.
The flow in the newest version is different, and when ExternalService is defined in a different zone then the request will go through local ZoneEgress to ZoneIngress in zone where ExternalService is defined and leave the cluster through ZoneEgress in this zone.
To keep the previous behavior, remove the kuma.io/zone tag from the ExternalService definition.
Previously, when mTLS was configured and ZoneEgress was deployed, requests were automatically routed through ZoneEgress.
You must now explicitly set that traffic should be routed through ZoneEgress by setting routing.zoneEgress: true in the Mesh configuration. By default, this is set to false.
type:Meshname:defaultmtls:# mTLS is required for zoneEgress[...]routing:zoneEgress:true
The new approach changes the flow of requests to external services. Previously when there was no instance of ZoneEgress traffic was routed directly to the destination, now it won’t reach the destination.
Previously, a MeshGatewayInstance generated a Deployment and Service whose names ended with a unique suffix. With this release, those objects will have the same name as the MeshGatewayInstance.
In connection with the changes around MeshGateway and MeshGatewayRoute, the output schema of the <policy-type>/<policy>/dataplanes has changed. Every policy can now affect both normal Dataplanes and Dataplanes configured as builtin gateways. The configuration for the latter type is done via MeshGateway resources.
Every item in the items array now has a kind property of either:
SidecarDataplane: a normal Dataplane with outbounds, inbounds, etc.
MeshGatewayDataplane: a MeshGateway-configured Dataplane with a new structure representing the MeshGateway it serves.
Some examples can be found in the Inspect API docs.
The kuma.metrics.dataplane.enabled and kuma.metrics.zone.enabled configurations have been removed. Kuma always generates the corresponding metrics.
Removed support for the old Ingress (Dataplane#networking.ingress), which was used before Kong Mesh 1.3. If you are still using it, migrate to ZoneIngress first (see Kuma Upgrade to 1.2.0 section).
Migrate your kuma.io/sidecar-injection annotations to labels. The new version still supports annotations, but to guarantee that applications can only start with a sidecar, you must use a label instead of an annotation.
Configuration parameter kuma.runtime.kubernetes.injector.sidecarContainer.adminPort and environment variable KUMA_RUNTIME_KUBERNETES_INJECTOR_SIDECAR_CONTAINER_ADMIN_PORT have been deprecated in favor of kuma.bootstrapServer.params.adminPort and KUMA_BOOTSTRAP_SERVER_PARAMS_ADMIN_PORT.
You can’t use 0.0.0.0 or :: in networking.address. Use loopback instead.
The Kuma DP flag --admin-port and environment variable KUMA_DATAPLANE_ADMIN_PORT have been deprecated. The admin port should be specified in Dataplane or ZoneIngress resources.
Default role-based access control (RBAC) for zone control planes is now restricted to the admin role.
Performance continues to be significantly improved.
Authentication tokens are now more secure.
Before you upgrade from 1.5.0 make sure to review your RBAC configuration for zone control planes. In 1.5.1,
RBAC for zone control planes is restricted by default. For information on how to secure access to resources, see
the RBAC documentation.
Upgrades from 1.5.0 are otherwise seamless and no further steps are needed.
Role-based Access Control (RBAC) is now available.
Support for Windows installation on Universal (VMs) is now available.
Renewable tokens in Vault are now supported.
Starting with this version, the default API server authentication method is user
tokens. To continue using client certificates (the previous default
method), you’ll need to explicitly set the authentication method to client
certificates. This can be done by setting the KUMA_API_SERVER_AUTHN_TYPE variable to
A service map topology view is available that provides visualization of service traffic dependencies.
Support for mutual TLS in permissive mode is available, to support migrating applications into the service mesh.
You can now customize hostnames and ports for data plane proxies with a new virtual outbound policy.
You can more easily specify intermediate CAs with mTLS.
Upgrades from 1.3.0 are seamless, but note the following:
Outbounds generated internally are no longer listed in dataplane.network.outbound. On Kubernetes, they are automatically removed.
On Universal, to remove them you must recreate your Dataplane resources with kumactl apply. Or, if the proxy lifecycle is
managed by Kuma, restart the services.
You may notice some proxies or zones indicated as Offline in the GUI when you upgrade the control plane. This can happen if
upgrading all instances of the control plane takes more than five (5) minutes. It’s temporary, and occurs because of a new mechanism for
better tracking proxy and zone status. A heartbeat periodically increments the generation counter for Insights. The offline status
should disappear after all control plane instances are upgraded to 1.4.0.
New L7 Traffic Routing policy to route and modify HTTP traffic per path, method, header, or any other combination, with support for regex. Traffic can be modified before reaching the final destination.
New Rate-Limit policy to protect services from aggressive traffic. This policy can protect from downtime and improve the overall reliability of your applications.
The “Remote” control plane is renamed to “Zone” control plane. This means the “Ingress” resource is renamed “ZoneIngress”. Thanks to community users for providing the feedback that drove this effort.
Traffic Permissions now work with external services.
Improved performance of our DNS resolution.
More improvements, including a fix for GCP/GKE’s erratic IPv6 support.
The IP address or hostname that provides the KDS address when you install the control planes can change. Make sure that you update the address when you upgrade the remote control planes to the latest version.
Changes in values in Kong Mesh’s Helm chart:
kuma.controlPlane.mode now accepts the values standalone, zone, and global. zone replaces remote, which is still available in earlier versions.
kuma.controlPlane.globalRemoteSyncService is renamed to kuma.controlPlane.globalZoneSyncService.
kuma.controlPlane.tls.kdsRemoteClient is renamed to kuma.controlPlane.tls.kdsZoneClient.
⚠️ All installation scripts are updated to a new location because Bintray is shutting down. If you’ve written automation scripts that refer to the Bintray location, you need to update your scripts to point to the new location.
Transparent proxying is improved.
The GUI is improved.
The locality is now always set in a multi-zone deployment.
If you previously installed Kong Mesh with kumactl install control-plane --license-path=... | kubectl apply -f -,
you must first uninstall the previous version and then install the new version. All policies are removed when you uninstall,
so make sure to back up all related CRDs before you start. Then:
Install Kong Mesh for Kubernetes using kumactl install control-plane ... with any additional command-line arguments you require.
Delete the old Deployment, Service, Webhooks, and Validation hooks: