verinice.onprem im eigenen Rechenzentrum: Virtuelle Maschine oder Kubernetes-Cluster

Mit dem Auslaufen der Weiterentwicklung von verinice.PRO im Jahr 2027 steht der Umstieg auf die neue verinice-Generation an. Wer den Betrieb selbst verantworten möchte, wählt verinice.onprem. Dieser Beitrag erläutert die beiden Betriebsmodelle und worauf bei der Wahl zu achten ist – Alternativ schauen Sie das Video zum Thema. 

Ausgangslage: zwei Deployment-Varianten, eine Softwarebasis

Die neue verinice-Generation steht in zwei Deployment-Varianten bereit: verinice.cloud und verinice.onprem. Beide setzen auf der neuen verinice-Plattform und damit auf derselben Softwarebasis auf. Der Funktionsumfang ist identisch, der Unterschied liegt allein im Betriebsmodell:

• Bei verinice.cloud übernimmt SerNet den Betrieb als SaaS.
• Bei verinice.onprem liegt die Betriebsverantwortung beim Kunden – so, wie es von verinice.PRO bekannt ist.

Wichtig: Auch der Betrieb in einer angemieteten Public Cloud zählt zu verinice.onprem, sofern der Kunde den Betrieb selbst verantwortet.

Variante 1: Betrieb als virtuelle Maschine mit verinice.onprem Virtual Appliance

Die erste Variante dürfte Bestandskunden vertraut sein. Unterstützt werden gängige Hypervisoren wie Proxmox VE und VM Ware; der Betrieb erfolgt im eigenen Rechenzentrum oder in einer privaten Cloud.

Talos Linux als sichere Basis

Als Betriebssystem der VM-Appliance kommt Talos Linux zum Einsatz: eine Distribution, die speziell für den Kubernetes-Betrieb entwickelt wurde und konsequent dem Prinzip *Security by Design* folgt. Alle nicht benötigten Komponenten sind deaktiviert: Es gibt kein SSH und keine interaktive Shell, das Dateisystem ist read-only. Selbst ein erfolgreicher Angriff könnte keine Daten verändern, die Angriffsfläche ist damit deutlich reduziert.

Single-Node-Cluster: alles in einer VM

Damit Kunden nur eine einzige virtuelle Maschine betreiben müssen, läuft die Appliance als Single-Node-Kubernetes-Cluster: Alle Softwarekomponenten sind in einer VM zusammengefasst. Das ermöglicht eine standardisierte Installation auf Basis eines einheitlichen Images – individuell anzupassen sind im Wesentlichen IP-Adresse und interner DNS-Name. Der Vorteil ist die klare Trennung zwischen Plattform (Hypervisor) und Anwendung (VM): Was innerhalb der VM geschieht, müssen Kunden in der Regel nicht selbst verwalten.

Variante 2: Betrieb als verinice.onprem Kubernetes-Cluster

Wer bereits einen eigenen Kubernetes-Cluster betreibt, kann verinice.onprem direkt dort ausrollen; ein vorhandenes Betriebs- und Sicherheitskonzept lässt sich unmittelbar übertragen. Da verinice.veo eine Cloud-native Applikation ist, profitiert dieser Weg von hoher Skalierbarkeit und – durch die Verteilung über mehrere Nodes – von hoher Verfügbarkeit. Empfohlen wird der parallele Betrieb einer Stage- und einer Produktionsumgebung, sodass neue Releases vor der Überführung getestet werden können.

Deployment über Container-Registry und Helm-Chart

Das Ausrollen erfolgt über eine bereitgestellte Container-Registry mit Docker Images und einem Helm-Chart, die für alle Kunden identisch sind. Eine zentrale Herausforderung: Kubernetes-Umgebungen unterscheiden sich teils erheblich. Statt je Kunde ein eigenes Chart zu pflegen, integriert SerNet die Besonderheiten in ein einziges, gemeinsames Helm-Chart, das alle bekannten Umgebungen abdeckt und bei Bedarf erweitert wird.

Höhere Anforderungen an den Betrieb

Beim Kubernetes-Betrieb verlaufen die Grenzen zwischen Plattform und Applikation fließend – das gilt besonders für das Zertifikatsmanagement. Da es sich um eine Webanwendung handelt, sollen keine Browserwarnungen auftreten. Drei Wege bieten sich an:

1. Eigene CA: Die unternehmenseigene Zertifizierungsstelle (z. B. eine Windows-CA, der die Clients bereits vertrauen) stellt ein Subordinate CA Zertifikat bereit.
2. Selbstsigniertes Zertifikat: technisch am einfachsten, wegen der Browserwarnungen aber nicht empfehlenswert.
3. Let's Encrypt: die bevorzugte Lösung, sobald die Infrastruktur dies zulässt.

Für den Cluster-Betrieb ist ein dedizierter Ansprechpartner auf Kundenseite erforderlich – idealerweise aus dem Applikationsteam –, der zwischen Plattformbetrieb und Anwendung vermittelt. Auch das Rollout neuer Releases liegt beim Kunden; SerNet unterstützt mit Best-Practice-Ansätzen oder passenden Support-Paketen.

Authentifizierung: Anbindung an AD und Entra ID

Für die Anbindung an bestehende Verzeichnisdienste steht die Integration mit Active Directory und Microsoft Entra ID zur Verfügung – technisch auf Basis von Keycloak.

Welche Variante passt zu wem?

Die VM-Variante hat die niedrigste Einstiegshürde: Meist ist bereits ein Hypervisor vorhanden, und verinice.onprem tritt schlicht an die Stelle der bisherigen verinice.PRO-Appliance. Für die Mehrheit der Bestandskunden ohne Cloud-Nutzung ist dies der naheliegende Weg.

Der Kubernetes-Betrieb ist technisch anspruchsvoller und richtet sich an Organisationen, die bereits eine Kubernetes-Plattform mit entsprechendem Know-how etabliert haben. Sie profitieren dafür von der Skalierbarkeit und Verfügbarkeit der Cloud-nativen Architektur.

Ein späterer Wechsel ist möglich: Wer mit der VM-Variante startet, kann seine Daten über eine Exportfunktion in eine Kubernetes-Umgebung überführen.

Optionale Service-Pakete: Installation, Wartung, Support

Den Eigenbetrieb müssen Sie nicht allein stemmen – im verinice-Shop lassen sich drei Pakete dazubuchen: der Installations-Support (Einrichtung als VM-Appliance oder im Kubernetes-Cluster inkl. Zertifikaten, Datenbank- und IDM-Anbindung, betriebsfertige Übergabe, remote oder vor Ort), der Update-Support (bis zu viermal jährlich neue Versionen und Security-Patches, bei der Virtual Appliance auf Wunsch mit Linux-Updates, auch mehrjährig buchbar) und das Support-Budget (Stundenkontingent für verinice sowie angrenzende Themen wie Datenbanken, Identity-Management und Virtualisierung). Wer den Betrieb ganz abgibt, findet in verinice.cloud die von der SerNet selbst betriebene Alternative; für die fachliche Begleitung steht das zertifizierte Partner-Netzwerk bereit.

Sie planen den Umstieg von verinice.PRO auf verinice.onprem? Sprechen Sie uns an – wir klären gemeinsam, welches Betriebsmodell zu Ihnen passt.