Service mesh Istio has made its 1.7 version available, sporting security and operability improvements, while pushing VM integration forward to get the project closer to becoming a “gloriously dull” staple.
Lately, Istio has been anything but boring, especially after originator Google came into some criticism for handing the project’s trademarks over to its recently founded Open Usage Commons. The step led to some turmoil, raising questions about how neutral OUC really was as well as basically smothering the hopes of those who had wished for Istio to become a CNCF project one day. According to IBM, a founding member of the project, there had actually been an “agreement” to do so with Google, which only seems sensible, given that the Envoy proxy, which is central to Istio, has found a vendor-neutral home at the organisation.
Despite the commotion, the Istio team has been able to move some aspects of the service mesh forward, making it easier to use on a day-to-day basis, amongst other things. Ops personnel are now, for example, only able to start an application once the sidecar is up and running, so that the app is immediately able to access resources via its proxy. The new version also allows the combination of the Istio Operator and canary control plane deployments, which is meant to make upgrades a bit less error-prone.
Istio’s tool to find out about configuration problems, istioctl analyze, has meanwhile learned to warn users when a deprecated Mixer resource has been used or if a potentially insecure DestinationRule configuration was found. Certificates for the latter weren’t served via the project’s secret discovery service (SDS) when mounted as files in earlier versions, which has also been fixed facilitating security best practices such as automatic rotation.
Speaking of SDS, Egress Gateways that do TLS/mTLS origination can provision client certificates as secrets in version 1.7. Istio has also tried to counter the unfortunately widespread custom to run everything as root by changing the defaults for Gateway deployments. Like that, users are nudged to think about the permissions actually needed by their processes, which helps to reduce a system’s attack surface.
Other than that, trust domain validation has been enhanced to not only validate HTTP traffic but also trustDomainAliases in the MeshConfig resource, and the tool has learned to communicate to a certificate authority using ECC cryptography. To get more insight into the mesh’s doings, Istio-agent metrics are now available for consumption.
Since multi-tenancy is still a bit of a sore subject, contributor IBM decided to invest some resources into the topic. The result, Central Istiod, is now in alpha stadium, and supposed to signify a first step towards the realisation of logically isolated instances in a shared environment. The approach “enables mesh operators to install and manage the mesh control plane on dedicated clusters, separated from the data plane clusters.”
Once it comes to full fruition, the addition will surely help to get more large enterprises behind the project.
Another group of enhancements that could help with that concerns itself with the use of non-Kubernetes workloads running in VMs, which helps to incorporate older business logic, especially in transitional periods.
Though basic functionality for this could be found in the mesh for a while, Istio 1.7 ensures that VMs running in the mesh are handled securely, follow best practices such as automatic certificate rotation, and istioctl also takes a look into a proxy’s status for such workloads. Users interested in those capabilities should be aware that it is still in alpha, so they’re still subject to change.