ManagementPlane

Portée : namespaced · Optionnel (la console est déployée par défaut)

La Navique AI Core Management Plane est la console d'administration de toute la plateforme — une interface web unique pour visualiser tout ce que l'opérateur gère, activer une licence et (lorsque la licence le permet) exporter la manière dont les utilisateurs ont utilisé le gateway IA. L'opérateur la déploie par défaut, même en l'absence de toute resource ManagementPlane ; cette resource ne fait que surcharger les valeurs par défaut (host, ingress, SSO, image, découverte).

• Qu'est-ce que le management plane
• Pourquoi est-ce utile
• Comment ça fonctionne
• Connexion et accès
• Activer une licence depuis la console
• Audit et export d'utilisation (sous licence)
• Sécurité et limites
• Spécification
  • Routage
  • Découverte
  • auth
• Ce que le contrôleur réconcilie
• Singleton de cluster & relocalisation
• Exemple
• Réglage du cache
• Statut

Qu'est-ce que le management plane

C'est une console d'administration propriétaire — le pendant à code fermé de l'opérateur open source. Là où l'opérateur exécute la plateforme, le management plane offre à un humain une vue unifiée sur celle-ci :

• Visualiser chaque resource gérée par l'opérateur et son statut en temps réel en un seul endroit, au lieu d'exécuter kubectl sur une douzaine de custom resources réparties dans plusieurs namespaces.
• Visualiser et activer la licence de la plateforme depuis un navigateur.
• Pour les acheteurs réglementés, exporter l'utilisation du gateway / l'historique de conversation d'un utilisateur sur une fenêtre temporelle au format JSON ou CSV (une fonctionnalité sous licence).

Elle est livrée uniquement sous la forme d'une image de conteneur préconstruite et est réservée aux administrateurs en v1. Parce qu'elle est propriétaire, elle ne se lie délibérément pas au code AGPL de l'opérateur — elle lit les resources de l'opérateur via l'API Kubernetes comme n'importe quel autre client. (Une vérification au moment du build échoue si un paquet de l'opérateur est lié.)

Pourquoi est-ce utile

Capacité	Disponibilité
Visualiser les resources gérées par l'opérateur + leur statut en temps réel à travers les namespaces	Base gratuite (toute licence / aucune licence)
Découvrir les instances LiteLLM / Langfuse en cours d'exécution et leur accessibilité	Base gratuite
Visualiser et activer une licence (crée/met à jour la resource License)	Base gratuite — la seule action en écriture
Exporter l'utilisation du gateway / l'historique de conversation d'un utilisateur (audit, JSON/CSV)	Sous licence : management-plane-audit-export

Les fonctionnalités soumises à licence échouent en mode fermé sans le droit correspondant ; la base gratuite est toujours disponible, même sans aucune licence.

Comment ça fonctionne

La console est un BFF d'agrégation d'API (backend-for-frontend), et non un pipeline d'observabilité ni une base de données. Un backend Go sert une application monopage Nuxt + Vue (intégrée dans le binaire, il n'y a donc pas de Node à l'exécution — idéal pour les installations en air-gap) ainsi qu'une API JSON. Elle lit depuis trois sources et ne stocke aucune donnée de plateforme qui lui soit propre :

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)

• API Kubernetes (via le client dynamique + le ServiceAccount de la console) — les resources de l'opérateur et leur .status, ainsi que la lecture et l'écriture de la License.
• API LiteLLM — utilisation, dépenses et activité par utilisateur final (la source principale d'audit).
• API Langfuse — traces de conversation (contenu d'audit complémentaire).

Les identifiants pour LiteLLM/Langfuse sont lus depuis des Kubernetes Secrets via le ServiceAccount de la console et ne parviennent jamais au navigateur. Le backend met en cache la liste des resources et les instances découvertes afin que le tableau de bord soit instantané (voir Réglage du cache).

Connexion et accès

Deux méthodes de connexion, toutes deux intégrées :

• Administrateur local — un administrateur d'amorçage, pour les clusters sans SSO ou en air-gap. Activez-le sous auth.localAdmin. Si vous ne fournissez pas de credentialsSecretRef, l'opérateur génère automatiquement les identifiants : il crée un Secret géré par l'opérateur navique-management-plane-console contenant le username (depuis localAdmin.username, par défaut admin) et un password aléatoire, et enregistre le nom du Secret dans status.localAdminSecret. Lisez le mot de passe généré avec :

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

  Fournissez une credentialsSecretRef (un Secret avec les clés username et password) uniquement si vous souhaitez gérer les identifiants vous-même.

• Microsoft Entra OIDC — configurez l'issuer, le client ID et le client secret ; le bouton SSO apparaît alors automatiquement.

Configurez l'une ou l'autre via le bloc auth de cette resource. L'opérateur génère également une clé SESSION_KEY stable dans ce même Secret de console géré, afin que les connexions survivent aux redémarrages et à la montée en charge de la console.

Activer une licence depuis la console

L'activation d'une licence est la seule écriture que la console effectue. Depuis la page License, un administrateur colle ou téléverse un jeton de licence signé ; le backend vérifie la signature et prévisualise les droits décodés (fonctionnalités + limites d'instances) avant tout changement ; à la confirmation, il crée ou met à jour la resource License et son Secret sous-jacent. L'opérateur récupère alors les nouveaux droits lors de sa prochaine réconciliation.

C'est le même jeton signé utilisé partout — la console intègre la même clé publique Ed25519 que l'opérateur, de sorte qu'un jeton est interprété de manière identique des deux côtés. Voir Gérer une licence pour la voie CLI et Éditions et licences pour la signification des fonctionnalités et des limites.

Audit et export d'utilisation (sous licence)

La première fonctionnalité sous licence (management-plane-audit-export) permet à un administrateur d'exporter la manière dont un utilisateur final a utilisé le gateway sur une fenêtre temporelle. Elle vise les organisations réglementées qui doivent répondre à la question « qu'est-ce que cet utilisateur a envoyé à travers la plateforme IA, et quand ? »

• L'identité de l'utilisateur final est l'adresse e-mail de l'utilisateur (x-litellm-end-user-id), transportée de LibreChat → LiteLLM → Langfuse.
• LiteLLM est la source principale (horodatages, modèle, tokens, dépenses, statut et contenu de la requête lorsqu'il est stocké) ; Langfuse la complète avec un contenu de conversation plus riche lorsqu'il est disponible. Si Langfuse est absent, l'export fonctionne malgré tout à partir de LiteLLM seul et le signale.
• La sortie est un JSON ou CSV normalisé, transmis en flux (et non mis en mémoire tampon), avec un bloc meta consignant qui l'a exécuté, l'utilisateur ciblé, la fenêtre, l'instance et les sources utilisées.
• Les exports sont eux-mêmes audités. Chaque export écrit un enregistrement de méta-audit (identité de l'opérateur, utilisateur ciblé, fenêtre, format, nombre de lignes, sources) dans le journal de l'application et dans un sink durable au sein du cluster — répondant à la question « qui a exporté les données de qui, et quand ».

Le contenu des conversations est sensible : la fonctionnalité est réservée aux administrateurs, le contenu n'est jamais journalisé en clair, et l'export fait l'objet d'un méta-audit. La console respecte la rétention propre aux outils en amont — elle lit ce que LiteLLM/Langfuse conservent encore et ne stocke rien elle-même.

Sécurité et limites

• RBAC à moindre privilège. L'opérateur provisionne à la console un ServiceAccount dont la seule écriture est l'activation de licence ; tout le reste est en lecture seule (voir Ce que le contrôleur réconcilie).
• Compatible AGPL. La console propriétaire lit les resources de l'opérateur via le client dynamique Kubernetes et n'importe pas les paquets AGPL de l'opérateur, ce qui préserve la frontière open-core. L'opérateur se contente de référencer et de déployer l'image.
• Pas un remplacement de Langfuse. Langfuse reste l'outil de traçage des LLM ; la console est la surface d'administration transversale qui pointe vers lui et en extrait des données.
• Hors objectifs de la v1 : RBAC multi-tenant, gestion en écriture des instances/modèles/ équipes, et un store d'observabilité intégré — envisageables plus tard, hors périmètre aujourd'hui.

Spécification

Champ	Type	Description
image	string	Surcharge image/tag (par défaut : épinglée par l'opérateur)
ingress	object	Route publique de la console — host, TLS (cert-manager), className et api (Ingress / Gateway). Voir Routage
auth	object	OIDC (Entra) et/ou un administrateur local d'amorçage
discovery	object	Surcharges explicites de points d'accès, fusionnées avec la découverte automatique des CRs. Voir Découverte
resources	object	Requests & limits CPU/mémoire appliqués au conteneur de la console
replicas	int	Nombre de répliques de la console (par défaut 1)

Routage

La console est construite par l'opérateur (et non via un chart Helm) : l'opérateur émet donc lui-même sa route publique. Les deux API de routage sont prises en charge et sont sélectionnées selon la valeur par défaut applicable à tout le cluster PlatformConfig.spec.routing, surchargeable par console avec ingress.api :

• Ingress classique (api: Ingress, ou la valeur par défaut lorsqu'aucun mesh n'est actif) — l'opérateur crée un Ingress networking.k8s.io/v1 (nommé d'après la resource) routant host → le Service de la console. className, le TLS cert-manager (tls + clusterIssuer), le basicAuthSecret nginx et des annotations personnalisées sont pris en compte.
• Gateway API (api: Gateway, ou la valeur par défaut lorsqu'un mesh est actif) — l'opérateur émet une HTTPRoute rattachée au Gateway managé partagé. Cela requiert les CRDs de la Gateway API ; tant qu'elles ne sont pas présentes, la console signale une condition Waiting.

Découverte

Par défaut, la console découvre automatiquement les instances LiteLLM/Langfuse en cours d'exécution à partir de leurs CRs Gateway/Observability. discovery.litellmEndpoints / discovery.langfuseEndpoints ajoutent des URLs de points d'accès explicites qui sont fusionnées avec cette découverte automatique — utile pour les instances externes ou inter-clusters qui ne sont pas des CRs de l'opérateur. Ces points d'accès manuels apparaissent sur le tableau de bord et font l'objet de sondes d'accessibilité ; comme ils n'ont aucun Secret d'identifiants associé, les fonctionnalités nécessitant des identifiants (export d'utilisation/d'audit) restent disponibles uniquement pour les instances découvertes via les CRs.

auth

Champ	Description
oidc	Entra : issuerURL, clientID, clientSecretRef
localAdmin	Administrateur d'amorçage pour les configurations sans SSO / en air-gap

auth.localAdmin

Champ	Description
enabled	Active la connexion administrateur local
username	Nom d'utilisateur de connexion (par défaut admin)
credentialsSecretRef	Optionnel. Un Secret avec les clés username et password. À omettre pour que l'opérateur génère automatiquement les identifiants dans le Secret géré navique-management-plane-console

Ce que le contrôleur réconcilie

1. Un Deployment + Service + Ingress optionnel pour l'image du management-plane — une console par cluster (voir Singleton de cluster & relocalisation). Sans resource ManagementPlane, elle réside dans le namespace système (par exemple navique-system) ; avec une resource, elle réside dans le namespace de cette resource.
2. Un ServiceAccount avec RBAC à moindre privilège :
   • get/list/watch au niveau cluster sur toutes les resources *.core.navique.com et /status ;
   • get sur les Secrets d'identifiants LiteLLM/Langfuse ;
   • create/update/get sur licenses.core.navique.com et le Secret de licence (la seule écriture de la console — l'activation de licence) ;
   • create/patch sur events (un sink de méta-audit).
3. La configuration depuis la resource ManagementPlane si elle est présente ; sinon des valeurs par défaut raisonnables.

Singleton de cluster & relocalisation

La console détient des droits RBAC à l'échelle du cluster ; en exécuter plus d'une n'a donc jamais d'intérêt. L'opérateur garantit exactement une console par cluster :

• Par défaut (aucune resource) : la console s'exécute dans le namespace système (navique-system).
• Relocalisation : appliquez une ManagementPlane dans un autre namespace et l'opérateur déplace l'unique console vers celui-ci — il la crée dans votre namespace et supprime la console par défaut dans navique-system. Il n'y a jamais de deuxième console. Supprimez la resource et la console revient dans navique-system.
• Plus d'une resource : la plus ancienne ManagementPlane l'emporte et pilote la console ; chaque resource plus récente signale status.phase: Superseded (Ready=False, raison Superseded) et ne déploie rien. Supprimez l'active et la suivante (la plus ancienne) est promue automatiquement.

Il s'agit d'un comportement purement contrôleur — aucune politique d'admission n'impose un nom particulier ; n'importe quel nom est accepté.

Exemple

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        # Ingress classique ; utilisez api: Gateway pour une HTTPRoute
    tls: true
    clusterIssuer: letsencrypt-prod
  resources:
    requests: { cpu: 100m, memory: 128Mi }
    limits:   { memory: 256Mi }
  discovery:
    # Instances externes / inter-clusters fusionnées avec la découverte automatique des CRs.
    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 omis → l'opérateur génère le nom d'utilisateur
      # + un mot de passe aléatoire dans navique-management-plane-console.

Réglage du cache

La console met en cache la liste des resources et les instances découvertes afin que le tableau de bord soit instantané. Ces paramètres sont réglables via l'environnement du déploiement (chacun est une durée Go ; valeurs par défaut indiquées) :

Variable d'env	Par défaut	Contrôle
RESOURCE_RESYNC_INTERVAL	10s	Resynchronisation en arrière-plan du cache de la liste des resources
INSTANCES_CACHE_TTL	15s	TTL pour la découverte d'instances + les sondes d'accessibilité
LICENSE_REFRESH_INTERVAL	60s	Fréquence à laquelle la License est relue et vérifiée

Statut

La disponibilité du Deployment, l'URL de console résolue, le localAdminSecret contenant les identifiants de l'administrateur local (lorsque l'administrateur local est activé), ainsi que les conditions et observedGeneration standard. Une resource non active (voir Singleton de cluster & relocalisation) signale phase: Superseded.