Skip to content

Overview

Important

This feature is in beta. We are actively engaged with early adopters and processing their feedback.

Service Mesh Manager is an out-of-the-box offering that allows platform teams and developers to secure inter-service communication and configure traffic routing rules for applications via Istio without sacrificing governance, access control and QoS. The solution includes:

  • Out of box observability with dashboards to monitor service-service communication in real time and retrospectively
  • Access control to configuration and visibility based on roles and assets. This allows platform teams to unblock developers and allow them to view traffic for their respective applications/namespaces while still maintaining RBAC control
  • Assignment of policies and rules to multiple levels of infrastructure including cluster and namespaces and ability to fine-tune based on application needs
  • Selectively enable mTLS across different parts of the infrastructure based on organizational or specific application needs
  • Standardization of policies across the infrastructure via blueprinting

The Service Mesh Manager offering is built on top of a popular service mesh offering, Istio. Visit us here for a quick Service Mesh Manager Demo

Using the console, API, RCTL, or GitOps, an admin can create rules and policies

  • Cluster: these policies are scoped at the cluster level and should be used to enforce default sets of rules across the cluster
  • Namespace: these policies are scoped at the namespace level and should be used to protect individual pods or applications in a given namespace

The creation of cluster-wide policies versus namespace policies have different workflows and require certain roles. See the RBAC section below to learn more. These policies can then be assigned to the appropriate assets and standardized across your project infrastructure.

Ideal Use Cases

The Service Mesh landscape is very deep, complex and nuanced. This service has been specifically designed and targeted for "very specific" use cases described below.

Good Fit

  1. Primarily requires the use of a Service Mesh primarily to 'enforce" the use of mTLS to secure "service-service" communications to demonstrate compliance (e.g. SOC-2)

  2. Requires a turnkey, low touch experience with a Service Mesh i.e. does not have the expertise or interested in dealing with the configuration and operational details of a Service Mesh.

  3. Does not wish to tune or customize the Istio configuration extensively

Alternatives

Important

If your requirements from a service mesh go beyond this list (e.g. deep customization, cluster-to-cluster policies), we recommend alternatives described below.

Alternative 1

Customers that prefer upstream service mesh options can follow our guides for "Istio" and "Linkerd".

Alternative 2

Customers that prefer a commercial option can work with our technology partners such as Tetrate. We have several mutual customers and these offerings are available and directly integrated in our Partner Catalog

Tetrate Catalog

Visibility & Governance

Users have real-time and historical visibility into traffic flows associated with the managed service mesh. This can be used to:

  • Validate whether service mesh rules are in effect by visualizing traffic flows
  • Monitor application performance and availability
  • Troubleshoot applications based on real-time and historical workflows

Service Mesh visibility

Role based Access Control (RBAC)

The following table lists the roles that can access specific components of the offering.

Feature Roles
Profile (Create, Update, Delete) Infra Admin, Org Admin
Profile (View) Infra Admin, Org Admin (Read-only roles), Cluster Template User
Cluster-wide Policies (Create, Update, Delete) Infra Admin, Org Admin
Cluster-wide Policies (View) Infra Admin, Org Admin(Read-only roles), Cluster Template User
Namespace Policies (Create, Update, Delete) Org Admin , Infra Admin, Workspace Admin, Project Admin
Namespace Policies (View) Org Admin , Infra Admin, Project Admin (read-only roles), Namespace Admin, Cluster Template User
Dashboard Visibility All except Cluster Template User

Pre-requisites

  • The Monitoring & Visibility Add-On (Prometheus) is required for dashboard visibility

  • If planning to use external cert-manager, this needs to be pre-installed

  • Service Mesh is cluster type agnostic and the below cluster types are tested and supported:

Cluster Type
Amazon EKS
Azure AKS
VMware vSphere
GKE
Upstream
Imported

Considerations

Any existing pods/workloads prior to to sidecar injection being enabled must be RESTARTED in order for policies to take effect. When sidecar injection is disabled, pods/workloads must be RESTARTED for the sidecars to no longer run.

Istio Versions

Istio 1.15.0 is the version that is currently deployed as part of this service. Updated versions of Istio will be supported in the near future. For more info on Istio releases, navigate to this URL.