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.
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.
Istio 1.15.0 is the version that is currently deployed. More info on Istio releases is available here.
Users have real-time and historical visibility into traffic flows. 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
The following table lists the roles that can access specific components of the offering.
|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 & Considerations¶
- 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:
- 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.