The Hubble UI draws the live service map: which workloads talk to which, and where traffic is dropped, updating as connections happen. It is the quickest way to see a namespace's real dependencies. It also has no login, so how you reach it matters more than usual.

> [!WARNING]
> The Hubble UI shows the full cluster flow data to anyone who can reach it, with no login screen. Never expose it on a `type: LoadBalancer` Service on a cluster shared by more than one team or reachable from the internet. That publishes your entire service map, unauthenticated, to anyone who reaches the IP.

## How to reach it

<Tabs id="hubble-ui-access" items={['Single operator', 'A team']}>
<TabItem value="Single operator">

Port-forward, so nothing is exposed to the network:

```console
$ kubectl port-forward -n kube-system svc/hubble-ui 12000:80
```

Then open `http://localhost:12000`. This is the right choice for a quick investigation by one person.

</TabItem>
<TabItem value="A team">

Put the UI behind an ingress that requires authentication, using the same identity provider your organization already uses. The UI has no login of its own, so that check has to happen at the ingress, through an auth proxy or your ingress controller's authentication support. It also has no per-namespace access control, so everyone who gets in can switch to any namespace. Give access only to people who should see cluster-wide traffic.

</TabItem>
</Tabs>

## Combine it with the other signals

Hubble shows network activity only. When you are investigating an incident, read it next to [audit logs](/docs/hetzner/apalla/observability/logs/ship-audit-logs), which show who changed the policy, and [node integrity](/docs/hetzner/apalla/security/verify-node-integrity), which shows whether a file changed on a node.