Skip to content

License ​

Geltungsbereich: Cluster · Singleton (muss cluster heißen)

Hält und validiert die signierte Offline-Lizenz und stellt jedem anderen Controller die freigeschalteten Features sowie die Instanz-Obergrenzen bereit. Lizenzen werden über das Navique-Kundenportal unter portal.navique.dev bezogen — heruntergeladen, gekauft oder als Testversion gestartet. Zum Lizenzmodell siehe Editionen & Lizenzierung und Eine Lizenz verwalten.

Spec ​

FeldTypBeschreibung
secretRefSecretKeyRef (erforderlich)Secret, das das signierte Lizenz-Token enthält. Standardschlüssel license.
yaml
apiVersion: core.navique.com/v1alpha1
kind: License
metadata:
  name: cluster                      # singleton — other names are rejected
spec:
  secretRef:
    name: navique-license
    key: license
    namespace: navique-system

Status ​

FeldBeschreibung
validOb das Token verifiziert und nicht abgelaufen ist
licenseeName der lizenzierten Entität
tierKomfort-Bezeichnung (enterprise / basic / …); wird nicht zur Durchsetzung verwendet
expiresAtAblaufzeitpunkt
environmentprod / nonprod
enabledFeaturesExplizite Feature-Flags, z. B. ["auto-wiring","guardrail"]
limitsDurchgesetzte Obergrenzen je Typ, z. B. {"gateways":3,"langfuse":1}
includedSupportHoursNur zur Referenz; wird außerhalb des Clusters nachverfolgt
reasonGrund, warum die Lizenz ungültig ist, falls zutreffend
revokedtrue, wenn das Token von der im Operator integrierten Widerrufsliste abgelehnt wurde
revokedReasonWiderrufskategorie, wenn revoked true ist: compromised / superseded / non-compliance / issued-in-error / unspecified
conditionsEnthält Ready (Grund LicenseRevoked, wenn widerrufen)

Wie die Verifizierung funktioniert ​

Die Lizenz ist ein signiertes JWT, das gegen einen öffentlichen Schlüssel verifiziert wird, der in das Operator-Binary einkompiliert ist (empfohlener Algorithmus: EdDSA / Ed25519; alg: none wird abgelehnt). Der Operator wählt den Verifizierungsschlüssel anhand des kid-Headers (Key-ID) des Tokens, sodass der Signierschlüssel rotiert werden kann, ohne bereits ausgestellte Lizenzen ungültig zu machen. Es gibt keinen Lizenzserver und keinen Phone-Home, sodass es auch in Air-Gap-Umgebungen funktioniert. Der Controller:

  1. Liest das Token aus dem referenzierten Secret und verifiziert die Signatur und den Ablauf.
  2. Prüft das Token gegen die im Operator integrierte Widerrufsliste (siehe Widerruf).
  3. Schreibt status (Gültigkeit, Lizenznehmer, Tier, Ablauf, Features, Limits, Umgebung, Grund) und eine Ready-Condition.
  4. Veröffentlicht die Berechtigungen an einen nebenläufigkeitssicheren Evaluator, den jeder Workload-Controller liest.
  5. Stellt kurz vor Ablauf erneut in die Warteschlange, damit das Gating rechtzeitig umschaltet.

Der Controller überwacht das referenzierte Secret: Eine neue Lizenz zu aktivieren, indem das Token an Ort und Stelle überschrieben wird (derselbe secretRef — so aktiviert die Management-Konsole eine Lizenz), wird sofort übernommen; die License-CR muss nicht bearbeitet oder erneut angewendet werden. Jeder lizenzabhängige Controller überwacht wiederum die License, sodass ein Upgrade oder Downgrade bestehende Instanzen umgehend neu bewertet — eine Komponente, die unter den alten Berechtigungen abgelehnt wurde, erholt sich, sobald die neue Lizenz verifiziert ist.

Widerruf ​

Eine Lizenz kann widerrufen werden, bevor sie abläuft — etwa wenn ihr Token durchsickert oder versehentlich ausgestellt wurde. Der Operator bringt eine in das Binary einkompilierte Widerrufsliste mit, sodass dies vollständig air-gapped funktioniert — ohne Online-Prüfung. Eine widerrufene Lizenz wird abgelehnt, obwohl ihre Signatur gültig ist, und der Operator fällt auf die Community-Standardwerte zurück — genau wie bei einer abgelaufenen Lizenz, sodass die Basisplattform weiterläuft.

Wenn eine Lizenz widerrufen ist, ist status.revoked true, status.revokedReason trägt die Kategorie (z. B. compromised), und die Ready-Condition meldet LicenseRevoked. Da die Widerrufsliste Teil des Operator-Binarys ist, übernehmen Sie Widerrufe (und die zusammen mit ihnen ausgelieferten Sicherheitskorrekturen), indem Sie den Operator aktuell halten. Kontaktieren Sie Navique, falls eine Ihrer Lizenzen unerwartet als widerrufen angezeigt wird.

Explizite Berechtigungen — kein Wildcard ​

Die Lizenz trägt eine aufgezählte features-Liste und quantitative limits. Es gibt bewusst keine Wildcard (["*"])-Berechtigung — jedes Feature und jede Instanzanzahl ist ein Preishebel und wird individuell durchgesetzt.

json
{
  "licensee": "ACME Bank AG",
  "issuer": "Navique",
  "tier": "enterprise",
  "features": ["auto-wiring", "guardrail", "multi-tenancy", "sso-scim", "audit-logging"],
  "limits": { "gateways": 3, "langfuse": 1, "chatui": 2, "teams": 10 },
  "environment": "prod",
  "includedSupportHours": 40,
  "issued_at": "2026-06-01T00:00:00Z",
  "expiration_date": "2027-06-01T00:00:00Z"
}

Community-Standardwerte (keine / abgelaufene Lizenz) ​

Wenn keine gültige Lizenz vorhanden ist — nie ausgestellt oder abgelaufen — wendet der Operator integrierte Community-Standardwerte an und die Plattform läuft weiter:

  • Kostenpflichtige Features deaktiviert (das Guardrail-Gate schlägt „fail closed“ fehl).
  • Instanz-Obergrenzen sinken auf das kostenlose Niveau (jeweils eine pro Typ).
  • Die Basisplattform bleibt unberührt.

Dies ist eine kontrollierte Herabstufung, kein Ausfall. Siehe Editionen & Lizenzierung.

Was sie freigibt ​

  • Feature-Flags — z. B. auto-wiring, guardrail, multi-tenancy, sso-scim, audit-logging sowie die management-plane-*-Familie, die von der Konsole genutzt wird.
  • Instanz-Obergrenzen je Typ — das Erstellen der Instanz N+1 über das lizenzierte Limit hinaus wird mit einer LicenseLimitExceeded-Condition abgelehnt (dies wird nicht als Fehler behandelt; die bestehenden Instanzen laufen weiter).

Die Kernplattform blockiert niemals aufgrund der Lizenz — nur die kostenpflichtigen Erweiterungen werden freigegeben, stets mit einem manuellen Rückfallpfad oder einem klaren Erneuerungsweg.

Open Core unter AGPL-3.0. Enterprise-Komponenten sind proprietär und lizenzgebunden.