Tetrate Service Bridge 1.5
After delivering the industry-first cloud agnostic application connectivity platform with the Tetrate Service Bridge Golden Gate release, Tetrate, founded by Istio creators, is now focusing on creating a better experience in the areas of security and operations for platform owners, including security teams, and application owners.
Tetrate is pleased to announce the general availability of Tetrate Service Bridge 1.5 release. TSB 1.5 will enable application and platform owners to leverage zero trust architecture, support for Helm charts, and a much improved Day 1 and Day 2 operations experience to better observe, run, control, and troubleshoot their applications and services across on-premises, single cloud, multi-cloud, and hybrid cloud environments.
This follows on from the Golden Gate release of Tetrate Service Bridge in February. Golden Gate combines basic API Gateway capability, a web application firewall (WAF), and service mesh capabilities into a single management plane, delivering a cloud-agnostic, unified application connectivity platform.
Hierarchical Policies
Hierarchical policies help organizations to manage policies for entire swathes of applications centrally, avoiding the need to re-implement identical policies on a per-team basis. Centralization and the elimination of duplicate efforts will ease operations, improve control, reduce configuration errors, improve operations, and potentially reduce security breaches.
Organization admins can configure default permissions at the org level or further down the hierarchy. Admins can then specify whether the default permission can be changed at lower level of the hierarchy, or restrict changes to tightening of policy only, with loosening of higher-level policy not allowed. Changes can be implemented during provisioning, tenant onboarding, or at the application deployment phase. Any type of mesh policy - traffic, security, or gateway policy - can be configured on the entire hierarchy - at the organization, tenant, workspace, or group level - by using this approach.
Restricted Hierarchical Policies
Security teams in any organization need to enforce certain regulatory and compliance requirements, such as enforcing encryption in transit, at the organization level. And they need to prevent these policies from being loosened further down the hierarchy. They do, however, often want to allow them to be tightened where necessary.
TSB addresses these requirements in the latest release by introducing Restricted Hierarchical Security Policy.
Security personas can set deny-all authorization policy as a default security setting at the organization level. They can then allow platform operators and application developers to override these security settings and explicitly set access control on workloads in the mesh which they operate. TSB will only allow changes that are stricter, not more relaxed, than the organization-wide policy.
Simplified GitOps Integration
GitOps support in TSB allows you to handle mesh configuration management in tandem with application deployment workflow. TSB 1.5 further simplifies GitOps integration by introducing Helm support for TSB installations and TSB API CRDs for application configurations, as described below.
Helm Support for TSB Installation
Installation of TSB management plane and control plane components can be facilitated and easily integrated to existing GitOps workflow using the dedicated Helm charts which we provide as part of the TSB 1.5 release. Follow instruction here to start using TSB Helm charts.
TSB APIs Available as Kubernetes CRDs
In most of the GitOps workflow scenarios today, mesh configuration management and automation is always a challenge, as you have a separation between the management plane cluster, where mesh configurations are applied, vs the application cluster, where application deployment manifests are applied. Application teams may not know the nuances of mesh configuration and the security and policy implications attached to it, so they are forced to depend on Platform teams to manage mesh configurations as a prerequisite for application deployment GitOps workflow.
TSB addresses these challenges in the 1.5 release. All TSB configuration objects are now available as Kubernetes custom resource definitions (CRDs) so that they can be easily applied to application clusters. TSB takes care of syncing those configurations to the management plane cluster. Now application teams can configure TSB resources using standard Kubernetes tooling (kubectl, Helm, Kustomize) and package them along with their application deployment manifests.
As shown in the figure below, once the resources are applied to the cluster, they will be automatically reconciled and forwarded to the management plane.
An example GitOps integration using FluxCD can be referred to here
Improved Day 2 Operation Experience
This release of TSB addresses some of the major Day 2 operation pain points that affect platform operators.
Canary Upgrade for Control Plane Components Using Revisions
Keeping up with Istio update cycles is a major pain point for customers who use open source Istio. Upgrading Istio in live production environments induces a high degree of risk. TSB 1.5 addresses this by introducing canary upgrades for control plane components using revisions, simplifying the Istio upgrade experience.
Config Status Propagation
When you deal with multi-tenant/multi-cluster service mesh setup, where different personas such as platform operators, security owners and application developers are involved in various stages of application deployment and delivery on a day-to-day basis, it is important to make it seamless and easy to collaborate, debug and troubleshoot the mesh platform when something goes south.
TSB has simplified the debugging and troubleshooting experience by introducing configuration status propagation. This offers a much improved feedback loop for platform operators and application teams, allowing them to confirm the state of the configuration for troubleshooting and as changes are in the process of being deployed. This can be directly monitored from the TSB UI.
Automatic Control Plane Token Rotation
TSB addresses cluster token management, token expiry, and token rotation pains for platform owners by introducing automatic control plane token rotation. With this latest addition, tokens generated for TSB internal components will be refreshed automatically by the control plane operator when they are about to expire, eliminating the need for manual intervention to refresh them. Go to Onboarding Clusters guide to see how to use service account to manage cluster token automatically.
Workload Onboarding Support for ECS and On-Premises VM
TSB 1.4 introduced workload onboarding capabilities that enable platform owners to easily add AWS EC2 and auto-scaling EC2 groups to the global mesh for unified management. TSB 1.5 adds more support for AWS ECS tasks and on-premises VM workloads. This makes TSB the only service mesh solution that supports heterogeneous compute out of the box.
Additional Improvements & Enhancements
- TCP support for gateways and services - TSB API now supports routing TCP traffic in gateways (for both Tier 1 and ingress gateways) and also for your services (via ServiceRoute). Learn how to configure TCP traffic here
- Istio EnvoyFilter and ServiceEntry support - TSB 1.5 adds a new config group, IstioInternal, where you can create Istio EnvoyFilters and ServiceEntries that will be distributed to specified namespaceSelectors defined in the group.
- Istio 1.12 - TSB 1.5 includes Istio 1.12 and brings all the latest Istio features and fixes.
- Kubernetes 1.22 and 1.23 support TSB now supports Kubernetes 1.22 and 1.23.
- Optional cert-manager installation - TSB 1.5 requires a certificate provider to support certificate provisioning for internal TSB components for purposes like webhook certificates and others. TSB 1.5 comes packaged with cert-manager and it can manage the lifecycle of cert-manager installation for you.
- Config protection - Customers can now enable configuration protection in TSB 1.5 to prevent accidental overwrites of TSB configurations in the control planes.
- Trust domain support for cross-cluster authorization - The Istio trust domain can be overridden for each ControlPlane cluster in TSB 1.5, so you can set up explicit authorization policies to enable cross-cluster authorization.
- Support for deploying gateways on VM - You can deploy Envoy proxy as a gateway in a virtual machine by setting an annotation on the WorkloadEntry.