ManagementPlane

Geltungsbereich: namespaced · Optional (die Konsole wird standardmäßig bereitgestellt)

Die Navique AI Core Management Plane ist die Administrationskonsole für die gesamte Plattform — eine einzige Weboberfläche, um alles zu sehen, was der Operator verwaltet, eine Lizenz zu aktivieren und (sofern lizenziert) zu exportieren, wie Benutzer das AI-Gateway genutzt haben. Der Operator stellt sie standardmäßig bereit, auch wenn keine ManagementPlane-Ressource existiert; diese Ressource überschreibt lediglich die Standardwerte (Host, Ingress, SSO, Image, Discovery).

• Was die Management Plane ist
• Warum sie nützlich ist
• Wie sie funktioniert
• Anmeldung & Zugriff
• Eine Lizenz über die Konsole aktivieren
• Audit- & Nutzungsexport (lizenziert)
• Sicherheit & Abgrenzungen
• Spec
  • Routing
  • Discovery
  • auth
• Was der Controller abgleicht
• Cluster-Singleton & Verlagerung
• Beispiel
• Cache-Tuning
• Status

Was die Management Plane ist

Es handelt sich um eine proprietäre Administrationskonsole — das Closed-Source-Gegenstück zum Open-Source-Operator. Während der Operator die Plattform betreibt, bietet die Management Plane einem Menschen eine zentrale Übersicht darüber:

• Jede vom Operator verwaltete Ressource und ihren Live-Status an einem Ort sehen, statt kubectl gegen ein Dutzend Custom Resources über Namespaces hinweg auszuführen.
• Die Plattformlizenz aus dem Browser sehen und aktivieren.
• Für regulierte Käufer die Gateway-Nutzung / den Konversationsverlauf eines Benutzers über einen Zeitraum als JSON oder CSV exportieren (ein lizenziertes Feature).

Sie wird ausschließlich als vorgefertigtes Container-Image ausgeliefert und ist in v1 ausschließlich für Administratoren. Da sie proprietär ist, verlinkt sie bewusst nicht den AGPL-Code des Operators — sie liest die Ressourcen des Operators über die Kubernetes-API wie jeder andere Client. (Eine Prüfung zur Build-Zeit schlägt fehl, falls ein Paket des Operators verlinkt wird.)

Warum sie nützlich ist

Fähigkeit	Verfügbarkeit
Vom Operator verwaltete Ressourcen + Live-Status über Namespaces hinweg anzeigen	Kostenlose Basis (beliebige / keine Lizenz)
Die laufenden LiteLLM- / Langfuse-Instanzen und deren Erreichbarkeit ermitteln	Kostenlose Basis
Eine Lizenz anzeigen & aktivieren (erstellt/aktualisiert die License-Ressource)	Kostenlose Basis — die einzige Schreibaktion
Die Gateway-Nutzung / den Konversationsverlauf eines Benutzers exportieren (Audit, JSON/CSV)	Lizenziert: management-plane-audit-export

Lizenzgebundene Features schlagen ohne die Berechtigung sicher fehl (fail closed); die kostenlose Basis ist immer verfügbar, selbst ganz ohne Lizenz.

Wie sie funktioniert

Die Konsole ist ein API-Aggregations-BFF (Backend-for-Frontend), keine Observability-Pipeline und keine Datenbank. Ein Go-Backend liefert eine Nuxt-+-Vue-Single-Page-Anwendung aus (im Binary eingebettet, sodass zur Laufzeit kein Node erforderlich ist — gut für Air-Gapped-Installationen) sowie eine JSON-API. Sie liest aus drei Quellen und speichert selbst keine Plattformdaten:

Admin browser ──▶ Nuxt SPA (served by Go via embed)
                      │  JSON BFF API
                      ▼
              Go backend (auth · discovery · license · audit · api)
                 │ Kubernetes API        │ LiteLLM API         │ Langfuse API
                 ▼ operator CRs + status ▼ usage / spend       ▼ conversation traces
                   License CR (read+write)  (audit primary)      (audit supplement)

• Kubernetes-API (über den dynamischen Client + das ServiceAccount der Konsole) — die Ressourcen des Operators und deren .status, zuzüglich des Lesens und Schreibens der License.
• LiteLLM API — Nutzung, Ausgaben und Aktivität je Endbenutzer (die primäre Audit-Quelle).
• Langfuse API — Konversations-Traces (ergänzender Audit-Inhalt).

Die Anmeldedaten für LiteLLM/Langfuse werden über das ServiceAccount der Konsole aus Kubernetes Secrets gelesen und erreichen niemals den Browser. Das Backend cacht die Ressourcenliste und die ermittelten Instanzen, damit das Dashboard sofort verfügbar ist (siehe Cache-Tuning).

Anmeldung & Zugriff

Zwei Anmeldemethoden, beide integriert:

• Lokaler Administrator — ein Bootstrap-Administrator, für Cluster ohne SSO oder mit Air-Gap. Aktivieren Sie ihn unter auth.localAdmin. Wenn Sie keine credentialsSecretRef angeben, generiert der Operator die Anmeldedaten automatisch: Er erstellt ein operatorseitiges Secret navique-management-plane-console mit username (aus localAdmin.username, Standard admin) und einem zufälligen password und vermerkt den Secret-Namen in status.localAdminSecret. Das generierte Passwort lesen Sie mit:

  kubectl get secret navique-management-plane-console -n navique-system \
    -o jsonpath='{.data.password}' | base64 -d

  Geben Sie eine credentialsSecretRef (ein Secret mit den Schlüsseln username und password) nur an, wenn Sie die Anmeldedaten selbst verwalten möchten.

• Microsoft Entra OIDC — konfigurieren Sie Issuer, Client-ID und Client-Secret; die SSO-Schaltfläche erscheint dann automatisch.

Konfigurieren Sie beides über den auth-Block dieser Ressource. Der Operator generiert außerdem einen stabilen SESSION_KEY in dasselbe operatorseitige Konsolen-Secret, damit Anmeldungen Neustarts und Skalierung der Konsole überstehen.

Eine Lizenz über die Konsole aktivieren

Die Lizenzaktivierung ist der eine Schreibvorgang, den die Konsole durchführt. Auf der Lizenzseite fügt ein Administrator ein signiertes Lizenz-Token ein oder lädt es hoch; das Backend verifiziert die Signatur und zeigt eine Vorschau der dekodierten Berechtigungen (Features + Instanzobergrenzen) an, bevor sich etwas ändert; nach der Bestätigung erstellt oder aktualisiert es die License-Ressource und das zugehörige Secret. Der Operator übernimmt die neuen Berechtigungen dann bei seinem nächsten Reconcile.

Es ist dasselbe signierte Token, das überall verwendet wird — die Konsole bettet denselben Ed25519-Public-Key wie der Operator ein, sodass ein Token auf beiden Seiten identisch interpretiert wird. Siehe Eine Lizenz verwalten für den CLI-Weg und Editionen & Lizenzierung zur Bedeutung der Features und Obergrenzen.

Audit- & Nutzungsexport (lizenziert)

Das erste lizenzierte Feature (management-plane-audit-export) ermöglicht es einem Administrator, zu exportieren, wie ein Endbenutzer das Gateway genutzt hat, über einen Zeitraum hinweg. Es richtet sich an regulierte Organisationen, die die Frage beantworten müssen: "Was hat dieser Benutzer durch die AI-Plattform gesendet, und wann?"

• Die Endbenutzer-Identität ist die E-Mail-Adresse des Benutzers (x-litellm-end-user-id), die über LibreChat → LiteLLM → Langfuse weitergereicht wird.
• LiteLLM ist die primäre Quelle (Zeitstempel, Modell, Tokens, Ausgaben, Status und Anfrageinhalt, sofern gespeichert); Langfuse ergänzt dies mit reichhaltigeren Konversationsinhalten, sofern verfügbar. Fehlt Langfuse, funktioniert der Export weiterhin allein aus LiteLLM und vermerkt dies.
• Die Ausgabe ist normalisiertes JSON oder CSV, gestreamt (nicht gepuffert), mit einem meta-Block, der festhält, wer ihn ausgeführt hat, den Zielbenutzer, den Zeitraum, die Instanz und die verwendeten Quellen.
• Exporte werden selbst auditiert. Jeder Export schreibt einen Meta-Audit-Eintrag (Operator-Identität, Zielbenutzer, Zeitraum, Format, Zeilenanzahl, Quellen) in das Anwendungsprotokoll und eine dauerhafte In-Cluster-Senke — und beantwortet damit "wer hat wessen Daten wann exportiert".

Konversationsinhalte sind sensibel: Das Feature ist ausschließlich für Administratoren, Inhalte werden niemals im Klartext protokolliert, und der Export wird meta-auditiert. Die Konsole respektiert die eigene Aufbewahrung der Upstream-Werkzeuge — sie liest, was LiteLLM/Langfuse noch vorhalten, und speichert selbst nichts.

Sicherheit & Abgrenzungen

• RBAC nach dem Least-Privilege-Prinzip. Der Operator stellt der Konsole ein ServiceAccount bereit, dessen einziger Schreibvorgang die Lizenzaktivierung ist; alles Übrige ist nur lesend (siehe Was der Controller abgleicht).
• AGPL-konform. Die proprietäre Konsole liest die Ressourcen des Operators über den dynamischen Kubernetes-Client und importiert die AGPL-Pakete des Operators nicht, sodass die Open-Core-Grenze gewahrt bleibt. Der Operator referenziert und stellt lediglich das Image bereit.
• Kein Ersatz für Langfuse. Langfuse bleibt das Werkzeug für LLM-Tracing; die Konsole ist die komponentenübergreifende Administrations-Oberfläche, die darauf verweist und daraus abruft.
• Nicht-Ziele in v1: mandantenfähiges RBAC, Rückschreibe-Verwaltung von Instanzen/Modellen/Teams sowie ein integrierter Observability-Speicher — später möglich, heute außerhalb des Geltungsbereichs.

Spec

Feld	Typ	Beschreibung
image	string	Image/Tag überschreiben (Standard: vom Operator gepinnt)
ingress	object	Öffentliche Route für die Konsole — host, TLS (cert-manager), className und api (Ingress / Gateway). Siehe Routing
auth	object	OIDC (Entra) und/oder ein lokaler Bootstrap-Administrator
discovery	object	Explizite Endpunkt-Überschreibungen, zusammengeführt mit der automatischen CR-Ermittlung. Siehe Discovery
resources	object	CPU-/Speicher-Requests & -Limits, die auf den Konsolen-Container angewendet werden
replicas	int	Anzahl der Konsolen-Replicas (Standard 1)

Routing

Die Konsole wird vom Operator erstellt (keine Helm-Chart), daher gibt der Operator ihre öffentliche Route selbst aus. Beide Routing-APIs werden unterstützt und gemäß dem clusterweiten Standard PlatformConfig.spec.routing ausgewählt, pro Konsole überschreibbar über ingress.api:

• Klassischer Ingress (api: Ingress oder der Standard, wenn kein Mesh aktiv ist) — der Operator erstellt einen networking.k8s.io/v1-Ingress (benannt nach der CR), der host → den Konsolen-Service routet. className, cert-manager-TLS (tls + clusterIssuer), nginx-basicAuthSecret und benutzerdefinierte annotations werden berücksichtigt.
• Gateway API (api: Gateway oder der Standard, wenn ein Mesh aktiv ist) — der Operator gibt eine HTTPRoute aus, die an das gemeinsam verwaltete Gateway angebunden ist. Erfordert die Gateway-API-CRDs; solange diese nicht vorhanden sind, meldet die Konsole eine Waiting-Bedingung.

Discovery

Standardmäßig ermittelt die Konsole die laufenden LiteLLM-/Langfuse-Instanzen automatisch aus deren Gateway-/Observability-CRs. discovery.litellmEndpoints / discovery.langfuseEndpoints fügen explizite Endpunkt-URLs hinzu, die mit dieser automatischen Ermittlung zusammengeführt werden — nützlich für externe oder clusterübergreifende Instanzen, die keine Operator-CRs sind. Diese manuellen Endpunkte erscheinen auf dem Dashboard und werden auf Erreichbarkeit geprüft; da sie kein zugehöriges Anmeldedaten-Secret besitzen, bleiben die anmeldedatengebundenen Features (Nutzungs-/Audit-Export) nur für per CR ermittelte Instanzen verfügbar.

auth

Feld	Beschreibung
oidc	Entra: issuerURL, clientID, clientSecretRef
localAdmin	Bootstrap-Administrator für Setups ohne SSO / mit Air-Gap

auth.localAdmin

Feld	Beschreibung
enabled	Aktiviert die lokale Administrator-Anmeldung
username	Anmelde-Benutzername (Standard admin)
credentialsSecretRef	Optional. Ein Secret mit den Schlüsseln username und password. Weglassen, damit der Operator die Anmeldedaten in das operatorseitige Secret navique-management-plane-console automatisch generiert

Was der Controller abgleicht

1. Ein Deployment + Service + optionaler Ingress für das Management-Plane-Image — eine Konsole pro Cluster (siehe Cluster-Singleton & Verlagerung). Ohne ManagementPlane-Ressource läuft sie im System-Namespace (z. B. navique-system); mit einer Ressource läuft sie im Namespace dieser Ressource.
2. Ein ServiceAccount mit RBAC nach dem Least-Privilege-Prinzip:
   • clusterweites get/list/watch auf alle *.core.navique.com-Ressourcen und /status;
   • get auf die Anmeldedaten-Secrets von LiteLLM/Langfuse;
   • create/update/get auf licenses.core.navique.com und das Lizenz-Secret (der einzige Schreibvorgang der Konsole — die Lizenzaktivierung);
   • create/patch auf events (eine Meta-Audit-Senke).
3. Konfiguration aus der ManagementPlane-Ressource, sofern vorhanden; andernfalls sinnvolle Standardwerte.

Cluster-Singleton & Verlagerung

Die Konsole besitzt clusterweite RBAC-Rechte, daher ist mehr als eine niemals sinnvoll. Der Operator erzwingt genau eine Konsole pro Cluster:

• Standard (keine Ressource): Die Konsole läuft im System-Namespace (navique-system).
• Verlagerung: Wird eine ManagementPlane in einem anderen Namespace angewendet, verschiebt der Operator die einzige Konsole dorthin — er erstellt sie in deinem Namespace und löscht die Standardkonsole in navique-system. Es gibt nie eine zweite Konsole. Wird die Ressource gelöscht, kehrt die Konsole nach navique-system zurück.
• Mehr als eine Ressource: Die älteste ManagementPlane gewinnt und steuert die Konsole; jede jüngere Ressource meldet status.phase: Superseded (Ready=False, Grund Superseded) und stellt nichts bereit. Wird die aktive gelöscht, wird automatisch die nächstälteste befördert.

Dies ist reines Controller-Verhalten — es gibt keine Admission-Policy, die einen bestimmten Namen erzwingt; jeder Name wird akzeptiert.

Beispiel

apiVersion: core.navique.com/v1alpha1
kind: ManagementPlane
metadata:
  name: management-plane
  namespace: navique-system
spec:
  ingress:
    enabled: true
    host: console.forge.example.com
    className: nginx        # klassischer Ingress; api: Gateway für eine HTTPRoute verwenden
    tls: true
    clusterIssuer: letsencrypt-prod
  resources:
    requests: { cpu: 100m, memory: 128Mi }
    limits:   { memory: 256Mi }
  discovery:
    # Externe / clusterübergreifende Instanzen, zusammengeführt mit der automatischen CR-Ermittlung.
    litellmEndpoints:  [ "https://litellm.other-cluster.example.com" ]
  auth:
    oidc:
      enabled: true
      issuerURL: https://login.microsoftonline.com/<tenant>/v2.0
      clientID: <app-id>
      clientSecretRef: { name: mp-oidc, key: client-secret }
    localAdmin:
      enabled: true
      username: admin
      # credentialsSecretRef weggelassen → der Operator generiert den
      # Benutzernamen + ein zufälliges Passwort in navique-management-plane-console.

Cache-Tuning

Die Konsole cacht die Ressourcenliste und die ermittelten Instanzen, damit das Dashboard sofort verfügbar ist. Diese sind über die Umgebung des Deployments einstellbar (jeweils eine Go-Dauer; Standardwerte angegeben):

Umgebungsvariable	Standard	Steuert
RESOURCE_RESYNC_INTERVAL	10s	Hintergrund-Resync des Ressourcenlisten-Caches
INSTANCES_CACHE_TTL	15s	TTL für Instanz-Ermittlung + Erreichbarkeitsprüfungen
LICENSE_REFRESH_INTERVAL	60s	Wie oft die License erneut gelesen und verifiziert wird

Status

Verfügbarkeit des Deployments, die aufgelöste Konsolen-URL, das localAdminSecret mit den lokalen Administrator-Anmeldedaten (wenn der lokale Administrator aktiviert ist) sowie die üblichen conditions und observedGeneration. Eine nicht aktive Ressource (siehe Cluster-Singleton & Verlagerung) meldet phase: Superseded.