Apparently, service mesh Istio currently comes with a high severity security issue. While waiting for the fix to roll around on February 22nd, users can now distract themselves with the just released version 1.13 of the project.
Most of the changes integrated into the release can be subsumed under the banner of traffic management. Developers now have a way of configuring concurrency and proxy image types via the ProxyConfig custom resource, and set up hostname-based multi-network gateways for east-west traffic.
There’s also support for rewriting gRPC probes, and listeners balancing between Envoy worker threads using proxyMetadata. Meanwhile Istio-agent learned to mimic Kubernetes’ probing approach since the last release, so that it won’t reuse connections anymore.
Another area of improvement was the Telemetry API introduced in v1.11. Amongst other things, practitioners can use the Common Expression Language to specify when requests or connections should be logged, and use the OpenTelemetry project for logging.
More general telemetry related enhancements include support for configurable service-cluster naming schemes and configs to select a service name generation scheme in trace spans generated by the Envoy service proxy.
Although the update doesn’t help with the yet to be specified security issue, it isn’t completely without safety improvements. Starting with the 1.13 release, the sidecar API comes with TLS settings to enable TLS/mTLS terminations on the sidecar proxy for requests from outside a mesh. WorkloadGroup and authorisation policy dry-run mode matured slightly, leaving them on v1beta1 and Alpha status respectively.
Users who experienced problems with endpoint scaling, rejected HTTP/1.0 requests, EnvoyFilter with patch contexts, or sidecar iptables before, could find themselves lucky, as these have been tackled in version 1.13 as well.
While upgrading to the latest Istio release should be relatively straightforward, users need to be aware of a couple of changes altering Istio’s behaviour. Developers creating custom kubeconfig files for endpoint discovery in multi-cluster installations for instance might have to enable their authentication method of choice manually, as out of the box methods have been cut down to enhance safety with the release.
The Istio team also got rid of the hardcoded logic around port 22 iptables capture, meaning that VM users will continue to have the port excluded while it will be included for Kubernetes users by default. If the latter isn’t wanted, the old behaviour can be restored using a traffic.sidecar.istio.io/excludeInboundPorts annotation. Details are available on the Istio website.