Explore the UI

Connect to the Solo UI and explore the basic layout. Review your Istio workloads, traffic flows, resources, and more.

About

The Solo UI deploys alongside your Istio ambient mesh environment in single or multicluster environments, and can discover existing ambient mesh installations across clusters and infrastructure providers. The UI works with ambient service meshes, whether you use community Istio images or Solo distributions of Istio.

Key features that you have access to when using the Solo UI include:

Visual service graph: Review what services can communicate with other services, the policies that are applied before traffic is sent to a service, and how traffic between services is secured.
Live metrics: With the built-in ClickHouse integration, the Solo UI has access to workload-specific metrics, such as the number of requests that were received for a workload. This data is visualized in the Solo UI graph. For more information about the ClickHouse integration, see ClickHouse.
Global services: In multicluster setups, you can review all services that are exposed globally across the multicluster mesh, including their hostnames, namespaces, localities, and host clusters.
Resource overview: With the Solo UI, you can view all Istio and Kubernetes resources in one place for all the clusters that you registered with the management server.

Note

The Istio ambient mesh views offer a view-only experience. Users cannot modify Istio resources from these views. If the same management UI also includes Solo Enterprise for agentgateway cost-management views, those views use the management backend access report to decide which Budget and Virtual Key actions the logged-in user can take.

Launch the UI

The Solo UI is served from the solo-enterprise-ui service. In a multicluster setup, this service exists in the cluster where the UI management components are deployed.

Get the IP address or hostname for the solo-enterprise-ui service.

export UI_ADDRESS=http://$(kubectl get svc -n solo-enterprise solo-enterprise-ui --context ${context1} -o jsonpath="{.status.loadBalancer.ingress[0]['hostname','ip']}")
echo ${UI_ADDRESS}

Open the UI in your browser.
```
open ${UI_ADDRESS}
```

Port-forward the solo-enterprise-ui service.

kubectl port-forward svc/solo-enterprise-ui -n solo-enterprise 4000:80 --context ${context1}

Open http://localhost:4000 in your browser.

Graph

The Graph page visualizes active connections between workloads in your service mesh. Use the Signal and Topology controls in the toolbar to switch between different perspectives and rendering modes.

Note

The graph shows no data until you select at least one cluster and one namespace from the filter dropdowns. Open the Clusters and Namespaces dropdowns and select what you want to review.

View modes

The graph has two view modes: Global view and Focus view.

Global view is the default. It shows the whole mesh at a consistent aggregation level with no pinned node. Only the clusters and namespaces you select in the filter bar are shown. Use the Group by selector below the filter bar to switch between Cluster, Namespace, Workload, and Node views. The Node view groups workloads by the Kubernetes node that runs them.

Focus view is entered when you pin a node or expand a cluster or namespace. In Focus view, a breadcrumb trail shows your position in the hierarchy, and a Depth selector appears beside it. The canvas background changes color to indicate that you are in Focus view. To exit, unpin the node or click Global view.

To pin a node, hover over it and click the pin icon, or double-click a service node. You can have a pinned node and a separately selected node at the same time. Pinning a node focuses the graph on it, and then you can click other nodes to view their connection details without changing the graph contents.

Layer views

The graph toolbar provides two independent controls for switching perspectives.

The Signal control switches the edge coloring and overlay between Traffic and Security.

Traffic: Shows active L7 traffic flows, with edges colored to indicate the health of requests between workloads. External workload nodes represent traffic to or from non-mesh peers, including egress to public hostnames and services declared in Istio ServiceEntry resources.
Security: Shows the security posture of connections. Edges are colored by the authorization policy verdict for the path, and a lock icon marks connections that are secured by mTLS. Click a node or a connection to view the governing policies, the evaluated source identity, and the mTLS and JWT posture. For more information, see Authorization policy coverage.

The Topology control switches the rendering between Application and Infrastructure.

Application (default): Shows logical service-to-service edges with mesh infrastructure hops collapsed.
Infrastructure: Renders real network flows, with waypoints shown as two-hop paths and east-west gateways shown as explicit cross-cluster intermediate nodes.

To open the Events drawer, which lists Kubernetes events for workloads in the current view, click Events in the filter bar. Enable Filter Graph in the drawer to highlight only nodes that have events.

Authorization policy coverage

In the Security signal, the graph evaluates the Istio AuthorizationPolicy, PeerAuthentication, and RequestAuthentication resources that apply to each workload, and colors every workload-to-workload path with the resulting verdict. The verdict follows Istio’s enforcement model, including the ambient split between ztunnel L4 and waypoint L7 enforcement, so that you can review which east-west paths are protected, open, or denied without reading raw YAML.

Figure: Security view with the authorization policy overlay

Verdict	Meaning
Allowed	An ALLOW rule admits this source and no DENY matches.
Denied	A DENY matches the source, or an ALLOW applies but admits no source, which is a deny by default.
Conditional	The verdict depends on a request attribute, such as an L7 match, a JWT, a `when` condition, or a source IP, that cannot be decided from a connection alone.
Unprotected	No `AuthorizationPolicy` applies to the destination, so the path is open.

Nodes are colored by coverage on the same scale. A namespace or cluster node rolls up the protected, unprotected, and conditional workload counts that it contains.

Note

An edge appears only where the UI has observed traffic. A policy that governs a path with no recent traffic is still counted in the destination workload’s coverage summary, but no edge is drawn for it.

Review the policies behind a verdict

Click a workload to see its coverage summary, the number of policies of each kind that apply to it, and the list of applicable policies. To read a policy in full, click View YAML.

To review one path instead of the whole workload, select a connection in the Outbound to or Inbound from list. The connection view adds the verdict for that path, the evaluated source identity that the verdict was computed against, and the mTLS posture.

Figure: Authorization details for a single connection

Fail-closed ambient paths

A Trap badge marks a path that Istio cannot enforce as written and therefore denies. The drawer reports this path as Effectively deny-all.

A trap bridge usually occurs when a selector binds an ALLOW policy to an ambient workload that has no waypoint, and the policy needs L7 enforcement. A policy needs L7 enforcement when it matches an HTTP host, method, or path; requires a JWT; or uses a when condition that the ztunnel cannot evaluate. Because the workload has no waypoint, the ztunnel is the only enforcement point, and the ztunnel enforces L4 only. The policy therefore admits nothing, and the path fails closed.

To resolve this, either attach a waypoint to the workload or rewrite the policy so that the ztunnel can enforce it.

This badge appears regardless of whether the highlight in the next section is on, because it reports a misconfiguration rather than a missing policy.

Highlight unprotected paths

Unprotected paths are always colored orange and dashed, and unprotected workloads always take a matching badge. In addition, the graph dims the paths and workloads that a policy governs, so that the open ones stand out.

Figure: Security view with unprotected paths highlighted

The dimming is on by default. To see every verdict at full strength instead, click Showing only unprotected paths in the toolbar. This setting controls only the dimming. It does not change the color of an unprotected path, and the legend always lists every verdict.

Review the policies on a waypoint

Set Topology to Infrastructure and click a waypoint to list every security policy attached to it, grouped by how the attachment resolves.

Group	Policies that it holds
Attached to the Gateway	Policies whose `targetRefs` name the waypoint’s `Gateway` resource.
Attached to the Gateway class (mesh-wide)	Policies in the mesh root namespace that target the waypoint’s `GatewayClass`.
Attached to enrolled services	Policies on the services that are enrolled on the waypoint through the `istio.io/use-waypoint` label.
Enforced by ztunnel on backends (L4)	Policies that the ztunnel applies at L4 to the ambient backends that the waypoint fronts.

Note

A verdict belongs to a client and backend pair, and the Infrastructure topology reattributes the source of each hop. When you combine Security with Infrastructure, edges therefore show their mTLS posture only, and the toolbar shows a caution chip. Workload coloring is unaffected. To restore the edge verdicts, click the chip or set Topology back to Application.

Figure: Caution chip shown when the Security signal is combined with the Infrastructure topology

Disable the overlay

The overlay is enabled by default. To turn it off, set the FLEETGRAPH_AUTHZ_OVERLAY_ENABLED environment variable on the UI backend.

helm upgrade -i solo-management \
oci://us-docker.pkg.dev/solo-public/solo-enterprise-helm/charts/management \
-n solo-enterprise \
--version ${SOLO_UI_VERSION} \
--reuse-values \
--set-string ui.backend.extraEnvs.FLEETGRAPH_AUTHZ_OVERLAY_ENABLED.value=false

Filters

Use the controls in the filter bar to scope the graph view.

Go to (or press ⌘F): Search for a workload by name. Results are grouped into Services, Namespaces, and External (for non-mesh hostnames), each showing the namespace and cluster context. Select a result to pin that node in the graph.
Clusters / Namespaces / Workloads: Select which clusters, namespaces, and workloads to include in the graph.
Nodes: Select which Kubernetes nodes to include in the graph.
Labels: Filter workloads by Kubernetes labels.

In Focus view, a Depth selector in the breadcrumb bar controls how much of the graph around the pinned node is drawn.

Depth	What the graph shows
Selected Only	The pinned node by itself.
1 Hop	The pinned node and the nodes that connect to it directly.
Full	Every node reachable from the pinned node along the connection path.

Graph settings

Click the gear icon at the bottom of the canvas to open Graph Settings.

General:

Animations: Enable or disable graph animations.
Show Idle: When enabled, includes nodes with no active connections in the graph. When disabled (default), idle nodes are hidden and excluded from search results.
Show Unregistered External Services: When enabled, includes external destinations that no Istio ServiceEntry declares. When disabled (default), only declared external services appear.

Performance:

Max nodes: Limits the number of nodes displayed. Default is 250. If the graph exceeds this limit, a message appears prompting you to apply more filters.

Time window

Use the preset buttons (5m, 15m, 30m, 1h) or the time range picker at the top of the page to control how far back the graph looks for traffic data.

Canvas controls

The toolbar on the left side of the canvas provides view controls.

+ / −: Zoom in and out.
Fit: Centers and fits the graph to the canvas.
Lock: Locks the graph so nodes cannot be moved.
Full screen: Expands the canvas to fill the screen. Press Escape to exit.
Reset layout: Resets the graph to the default node arrangement.

Danger thresholds

The bar at the bottom of the canvas sets the point at which the graph draws a connection as unhealthy. To show or hide the bar, click the danger thresholds icon next to the gear icon. Leave a field empty to apply no threshold of that kind.

Field	Description
Error Rate Danger Threshold	The error rate, as a percentage of requests, at which a connection counts as failing.
Latency Danger Threshold	The latency, in milliseconds, at which a connection counts as slow.

Connection details

Click any node to open the details panel on the right side of the screen. The panel shows outbound and inbound connections for the selected node, which you can filter by name and sort by different fields. To pin the node from the panel, click the pin icon in the panel header. For service-level nodes, the panel also shows HTTP request traffic metrics and a traffic-by-status breakdown for the selected workload.

Select a connection from the list to view Connection Details, including whether mTLS is active and the SPIFFE principals for both sides. For cluster-level nodes, the panel shows the cluster’s region and zone rather than connection security details, since security information is not available for aggregated views.

Resource YAML

To view the YAML definition of a workload, namespace, service, or Istio security policy, click its node in the graph and select View YAML from the details panel.

Global services

If you have a multicluster mesh setup, and made the in-mesh services available across clusters, the Global Services page lists the services that are exposed globally across the multicluster mesh. Use the Search, Visibility, and Clusters filters to find specific services.

Each row shows the following information for a global service.

Column	Description
Global Service	The name of the globally exposed service.
Namespace	The namespace the service belongs to.
Hosts	The mesh-internal hostname used to reach the service across clusters.
Visibility	The scope of the service exposure, such as `Global`.
Locality	The region where the service instances run.
Host Clusters	The clusters that host backend instances of the service.
Endpoints	The number of healthy backend endpoints out of the total, for example `3/3`.

To view traffic details for a global service, click its name. The detail view shows inbound traffic broken down by caller and by source-cluster locality. Use the source-cluster filter to narrow the data to a specific cluster.

Resources

Find an overview of resources that are deployed in your mesh environment and use the filter options in the Solo UI to find the resource that you need. To view the YAML configuration for a resource, click the resource’s name.

By default, the displayed resources are filtered to Istio CRs, such as ServiceEntries and AuthorizationPolicies, and Kubernetes Gateway API CRs, such as HTTPRoutes and GatewayClasses. In the Filters > GVK Type menu, you can optionally also select standard Kubernetes CRs, such as Deployments and StatefulSets, and kgateway CRs, such as GatewayParameters and TrafficPolicies.

Install Expand observability