We’re excited to announce the release of Aspen Mesh 1.5 which is based on Istio’s latest LTS release 1.5 (specific tag 1.5.2). Istio 1.5 is the most feature-rich and stable release since Istio 1.1 and contains many enhancements and improvements that we are excited about. With this release, Istio continues to increase stability, performance and usability. At Aspen Mesh, we’re proud of the work that the Istio community has made and are committed to helping it become even better. We continue to represent users’ interests and improve the istio project as maintainers and working group leads for key areas, including Networking and Product Security. It has been amazing to see the growth of the Istio community and we look forward to being a part of its inclusive and diverse culture.

Given the changes in the release, we understand that it can be challenging for users to focus on their key issues and discover how the new features and capabilities relate to their needs while adding business value. We hope this blog will make it easier for our users to digest the sheer volume of changes in Istio 1.5 and understand the reasons why we have, at times, chosen to disable or not enable certain capabilities. We evaluate features and capabilities within Istio from release to release in terms of stability, readiness and backwards compatibility, and we’re eager to enable all capabilities once they are ready for enterprise consumption.

Key updates in Istio 1.5 include: 

  • The networking APIs were moved from v1alpha1 to v1beta1 showing that they are getting closer to stabilizing; 
  • Enabling Envoy to support filters written in WebAssembly (WASM); 
  • The istio operator continues to make major strides in installing and upgrading Istio, as well as istioctl; 
  • A new API model to secure mutual TLS (mTLS) and JWT use in your service mesh.

The number of features added or changed by Istio is long and exciting, so let’s dig deeper into the changes, rationale behind them and how it will impact you as an Aspen Mesh customer.


New Security APIs

Istio 1.5 introduces new security APIs (PeerAuthentication, RequestAuthentication) that work in conjunction with Authorization Policy resources to create a stronger security posture for your applications. We understand that customers have widely adopted Authentication Policies, and the pain of incrementally adopting mTLS as well as debugging issues encountered. We believe that the new set of APIs are a step forward in the evolution of application security. With the older APIs being deprecated in Istio 1.5— and with the intent to remove these APIs in Istio 1.6—it is imperative that customers understand the work required to ease this transition.

To ease migration from the v1alpha1 APIs to the v1beta1 APIs Aspen Mesh has updated our dashboard to reflect mTLS status using the new APIs, we have updated our Secure Ingress API to use the new security APIs and we have updated our configuration generation tool to help you incrementally adopt the new APIs.


Challenges with Older APIs

While Authentication Policies worked for most of the use cases, there were architectural issues with the API choices.

Authentication Policies used to be specified at the service level, but were applied at the workload level. This often caused confusion and potential policy escapes as all other Istio resources are specified and applied at the workload level. The new API addresses this concern and is consistent with the Istio configuration model.

Authentication Policies used to handle both end user and peer authentication causing confusion. The new API separates them out as they are different concerns that solve different sets of problems. This logical separation should make it easier to secure your application as the possibility of misconfiguration is reduced. For example, when configuring mTLS if there is a conflict between multiple PeerAuthentication resources, the strongest PeerAuthentication (by security enforcement) is applied. Previously conflict resolution was not defined and behavior wasn’t deterministic.

Authentication Policies used to validate end user JWT credentials and reject any request that triggered the rule and had no or invalid/expired JWT tokens. The new API separates the Authentication and Authorization pieces into two separate composable layers. This has the benefit of expressing all allow/deny policies in a single place, i.e. Authorization resources. The downside of this approach is that if a RequestAuthentication policy is applied, but no JWT token is presented, then the request is allowed unless there’s a deny Authorization policy. However, separating authentication/identity and authorization follows traditional models of securing systems, with respect to access control. If you are currently using Authentication policies to reject requests without any JWT tokens, you will need to add a deny Authorization policy for achieving parity. While Istio has greatly simplified their security model, our Secure Ingress API provides a higher level abstraction for the typical use case. Ease of adoption is one of our core tenets and we believe that Secure Ingress does just that. Feel free to reach out to us with questions about how to do this.


Migration Towards New APIs

You don’t have to worry about resources defined by the existing Authentication Policy API as they will continue to work in Istio 1.5. Aspen Mesh supports the direction of the Istio community as it trends towards using workload selectors throughout its APIs. By adopting these new APIs we are hopeful that it will alleviate some application security concerns. 

With the removal of the v1alpha1 APIs in istio 1.6 (ETA June 2020) we are focused on helping our customers migrate towards using the new APIs. Our Secure Ingress Policy has already been ported to support the new APIs, as well as our tool to help you incrementally adopt mTLS. Note that our Secure Ingress controller preserves backward compatibility by creating both RequestAuthentication and Authorization policies as needed to ensure paths protected by JWT tokens cannot be accessed without tokens.

Users upgrading to Aspen Mesh 1.5.2 will see their MeshPolicy replaced with a mesh-wide PeerAuthentication resource. This was intentional, although upstream Istio chose not to remove a previously installed MeshPolicy, so that users can quickly migrate their cluster towards using the new security APIs. With that in mind, istioctl now includes analyzers to help you find and manage your MeshPolicy/Policy resources, giving you a deprecation message with instructions to migrate away from your existing policies.


Extending Envoy Through WASM

WASM support, as an idea, can be traced back to October 2018. A proxy ABI specification for WASM was also drafted with the idea that all proxies, and not just Envoy, can adopt WASM helping to further cement the Istio community as thought leaders in the service mesh industry. The Istio community also had major contributions to Envoy through the envoy-wasm repository to enable WASM support and is the fork of Envoy used in Istio 1.5. There are plans to have their hard work incorporated into the mainline Envoy repository.

This is a major feature as it will enable users to extend Envoy in new and exciting ways.

We applaud the Istio community for its work to deliver this capability. Previously writing a filter for Envoy required extensive knowledge of not only Envoy C++ code, but also how to build it, integrate it and deploy Envoy.

WebAssembly support in Envoy will allow users to create, share and extend Envoy to meet their needs. Support for creating Envoy extensions already exists with SDKs for C++, Rust, and AssemblyScript, and there are plans to increase the number of supported languages shortly. Istio is also continuing to build its supporting infrastructure around these Envoy features to easily integrate them into the Istio platform. There is also on-going work to move already existing Istio filters to WASM; in fact, Telemetry V2 is a WASM extension. Istio is eating its own dog food and the results speak for themselves. Expect future blogs around WASM capabilities in Istio as we learn more about its feature set and capabilities.

For more information, please see Istio’s WASM announcement


istiod and Helm Based Installs

Support for Helm v3-based installs continues to be a top priority for Aspen Mesh. Aspen Mesh Helm installation process is a seamless operation for your organization. Aspen Mesh 1.5 does not support the istiod monolith yet, but continues to ship with Istio’s microservice platform.

We are actively working with the Istio community to enable installations and upgrades from a microservice platform to the monolithic platform a first-class experience with minimal downtime in istio 1.6. This will ensure that our customers will have a stable and qualified release when they migrate to istiod.

As Istio has evolved, a decision was made to simplify Istio and transform its microservice platform to that of a monolith for operational simplification and overhead reduction. The upgrade path from microservices control plane to monolith (istiod) requires a fresh install and possible downtime. We want our customers to have a smooth upgrade and experience minimal downtime disruption.


Moving Towards a Simplified Operational System (istiod)

Benefits of a monolithic approach to end users, include a reduction in installation complexity and fewer services deployed which makes it easier for users to understand what is being deployed in their Kubernetes environment, especially as the intra-communication within the controlplane and the inter-communication between the control plane and data plane continues to grow in complexity. 

With the migration towards istiod, one of the key features that we anticipate will mature in istio 1.6 is the istio in-cluster Operator. In-cluster operators have quickly gained traction within the Kubernetes community and the Istio community has made a significant effort towards managing the lifecycle of Istio. A key feature that we are eager about is the ability to have multiple control planes, which would enable such things as canaries and potentially in-place upgrades. As the in-cluster operator continues to evolve we will continue to evaluate it and when we feel it is ready for enterprise use you should expect a more detailed blog to follow.


Other Features on the Horizon

As always, Istio and Aspen Mesh are constantly moving forward. Here is a preview of some new features we see on the horizon.


Mixer-less Telemetry

Many users have inquired about mixer-less telemetry, hence referred to as Telemetry V2. During testing, Aspen Mesh found an issue with TCP blackhole telemetry, others found an issue with HTTP blackhole telemetry and a few other minor issues were found. Aspen Mesh is committed to helping the Istio community test and fix issues found in Telemetry V2, but until feature parity is reached with Mixer telemetry we will continue to ship with Mixer, aka Telemetry V1. This is perhaps our most requested feature and we are eager to enable it. The work surrounding this has been a Herculean effort by the Istio community and we are eager to enable it in a future Aspen Mesh release.


Intelligent Inbound and Outbound Protocol Detection

While upstream Istio has previously enabled outbound intelligent protocol detection, Aspen Mesh has decided to disable it; the reasoning for this was detailed in our Protocol sniffing in production blog. For Istio 1.5, inbound intelligent protocol detection was also enabled. While this has the potential to be a powerful feature, Aspen Mesh believes that deterministic behavior is best defined by our end users. There have been a handful of security exploits related to protocol sniffing and we will continue to monitor its stability and performance implications and accordingly enable them if warranted in future releases.

For this and prior releases, we recommend our users continue to prefix the port name with the appropriate supported protocol as suggested here. You can also use our vetter to discover any missing port prefixes in your service mesh.


Next Steps for You

The Aspen Mesh 1.5 binaries are available for download here. If you have any questions about your upgrade path, feel free to reach out to us at support@aspenmesh.io.

If you’re new to Aspen Mesh, you can download a free 30-day trial here