Namespace-Scoping für Hubble UI mit Cilium OSS

Das Problem: Hubble UI kennt keine Mandanten Cilium und Hubble gehören für uns bei vielen Kubernetes-Projekten mittlerweile zum Standard-Werkzeugkasten. Hubble UI liefert dazu eine wirklich hilfreiche visuelle Sicht auf den Netzwerkverkehr im Cluster – wer redet mit wem, welche Verbindungen werden geblockt, wo hakt es.

Was Hubble UI in der Open-Source-Variante von Cilium jedoch nicht mitbringt, ist eine Mandantentrennung: Wer Zugriff auf die UI hat, sieht ausnahmslos alle Flows aus allen Namespaces des Clusters. In einem Cluster mit mehreren Teams oder Kundinnen und Kunden ist das schnell ein Problem, sobald man Entwicklerinnen und Entwicklern selbst Zugriff auf Hubble geben möchte, statt jede Abfrage über das Platform-Team laufen zu lassen.

Cilium Enterprise von Isovalent löst genau das mit Hubble RBAC: rollenbasierte, self-service Sichtbarkeit auf Flow-Daten, OIDC-integriert, als Teil des grösseren Enterprise-Feature-Sets. Für alle mit einer Enterprise-Lizenz ist das der naheliegende und empfehlenswerte Weg – ausgereift, unterstützt, und wir setzen das als Isovalent-Partner auch entsprechend ein.

Nicht jeder Cluster läuft aber (schon) mit Cilium Enterprise. Für alle auf der Open-Source-Variante gab es bislang nur die binäre Wahl: entweder niemand ausser der Plattform-Crew bekommt Zugriff auf Hubble UI, oder alle sehen alles. Genau diese Lücke schliesst hubble-authz-proxy.

Was das Projekt macht

hubble-authz-proxy ist ein schlanker Reverse-Proxy, der sich zwischen das Hubble-UI-Frontend und das unveränderte Hubble-UI-Backend schaltet. Anfragen lässt er unangetastet durch – erst bei der Antwort greift er ein und entfernt alles, was einen Namespace betrifft, auf den die anfragende Person keine Berechtigung hat, bevor die Antwort den Browser erreicht.

Bewusst macht der Proxy nur Autorisierung. Für die Authentifizierung – wer ist die anfragende Person überhaupt – ist weiterhin ein vorgelagerter Reverse-Proxy wie oauth2-proxy zuständig, der die Identität (Benutzername, E-Mail, Gruppen) als HTTP-Header mitgibt. Dahinter kann praktisch jeder OIDC-Provider stecken – Keycloak, Azure AD/Entra, oder z. B. auch Rancher, das sich selbst als OIDC-Provider betreiben lässt.

Für die eigentliche Autorisierung gibt es zwei Modi:

static – eine einfache YAML-Datei, die Gruppen oder Benutzer auf Namespaces abbildet. Schnell eingerichtet, muss aber manuell gepflegt werden und kann von der tatsächlichen Cluster-Berechtigung abweichen.

rbac – der Proxy fragt für jeden Namespace direkt beim Kubernetes-API-Server nach: „Darf diese Person hier Pods auflisten?“ (via SubjectAccessReview). Damit deckt sich die Sichtbarkeit in Hubble UI exakt mit dem, was die Person ohnehin schon über kubectl sehen würde – ohne zusätzliches Mapping, das aus dem Ruder laufen kann.

Ein paar technische Eckpunkte

Ohne zu tief ins Detail zu gehen, ein paar Entscheidungen, die für den produktiven Betrieb relevant sind:

• Filterung auf Antwort-Ebene statt auf der Anfrage. Der Proxy vertraut nicht darauf, dass die UI-Filter „brav“ gesetzt werden – er prüft, was tatsächlich zurückkommt. Wer die Filter der UI manipuliert, bekommt dadurch keinen breiteren Zugriff.
• Caching im rbac-Modus. Jede Sichtbarkeitsprüfung pro Namespace kostet eine echte Anfrage an den API-Server, darum wird das Ergebnis pro Identität zwischengespeichert (standardmässig 60 Sekunden). Damit ein Rechte-Entzug nicht bis zu einer Minute unbemerkt bleibt, kann der Proxy zusätzlich die relevanten RBAC-Objekte im Cluster beobachten (Roles, RoleBindings & Co.) und betroffene Cache-Einträge sofort verwerfen, statt auf den Ablauf des Caches zu warten.
• Fail-closed als Grundprinzip. Alles, was der Proxy nicht eindeutig kennt oder zuordnen kann – ein unbekannter Antworttyp, eine fehlende Berechtigung, ein Ausfall der Prüfung – führt zu einer Ablehnung, nie zu einem stillschweigenden Durchlassen.
• Sicherheitsmodell. Der Proxy vertraut den Identitäts-Headern des vorgeschalteten Auth-Proxys. Das ist nur sicher, wenn eine NetworkPolicy sicherstellt, dass ausschliesslich dieser Auth-Proxy den hubble-authz-proxy erreichen kann – und der Proxy wiederum als Einziger das eigentliche Backend.
• Beobachtbarkeit. Prometheus-Metriken zu Requests, Cache-Trefferquote, ausgestellten SubjectAccessReviews usw. sorgen dafür, dass der Betrieb den Filter im Auge behält, statt ihm blind zu vertrauen.

Wie man es einsetzt

Das Projekt bringt ein Helm-Chart mit und lässt sich entweder als eigenständiger Dienst vor das bestehende Hubble-UI-Backend stellen, oder direkt als zusätzlicher Container in den Hubble-UI-Pod integrieren. Die Konfiguration reduziert sich im Kern auf: Authentifizierung vorschalten (z. B. oauth2-proxy), Modus wählen (static oder rbac), und im static-Fall die Mapping-Datei pflegen.

Cilium Enterprise vs. hubble-authz-proxy – für wen ist was?

Uns ist wichtig, hier keine falschen Erwartungen zu wecken: hubble-authz-proxy ist keine Konkurrenz zu Hubble RBAC von Cilium Enterprise, sondern eine pragmatische Ergänzung für eine andere Ausgangslage.

Cilium Enterprise (Hubble RBAC) ist die offizielle, von Isovalent unterstützte Lösung. Sie dürfte tiefer in den Stack integriert sein als ein vorgeschalteter Proxy, ist Teil eines grösseren, kohärenten Enterprise-Feature-Sets (u. a. Hubble Timescape für historische Flow-Daten), und kommt mit professionellem Support und den Garantien, die eine kommerzielle Lösung mitbringt. Für alle mit entsprechenden Anforderungen an Support, SLAs oder zusätzlichen Enterprise-Funktionen bleibt das der empfohlene Weg – und der, den wir als Isovalent-Partner unseren Kundinnen und Kunden je nach Bedarf ebenso vorschlagen.

hubble-authz-proxy adressiert eine schmalere, aber konkrete Lücke: Cluster, die (noch) auf der Open-Source-Variante von Cilium laufen und trotzdem keinen unautorisierten Vollzugriff auf Hubble UI gewähren wollen. Das hat auch klare Grenzen: Der Proxy deckt ausschliesslich Hubble UI ab, nicht die Hubble-CLI oder einen direkten API-Zugriff – wer daran vorbeikommt, sieht wieder alles. Er hängt zudem am internen, nicht stabil versprochenen Wire-Format von hubble-ui und muss darum im Gleichschritt mit dem eingesetzten Hubble-UI-Image aktualisiert werden. Und er ist ein zusätzlicher Baustein im Betrieb – mehr als eine native, tief integrierte Lösung es wäre.

Kurz: Ein guter Zwischenschritt oder eine leichte Alternative für alle, die heute noch nicht auf Cilium Enterprise setzen, aber kein Sicherheitsproblem in Kauf nehmen wollen, nur weil die Budgetfreigabe für die Enterprise-Lizenz noch aussteht.

Code

Der Code ist auf GitHub verfügbar: github.com/puzzle/hubble-authz-proxy

Feedback, Issues und Pull Requests sind willkommen.