Die Architektur von openDesk verstehen: Kubernetes, Nubus und die Apps

Kurz gesagt: openDesk ist kein einzelnes Programm, sondern ein Verbund aus rund einem Dutzend Open-Source-Anwendungen, die als über 35 Helm-Charts auf einem Kubernetes-Cluster laufen und von Helmfile in fester Reihenfolge ausgerollt werden. Im Zentrum steht Nubus von Univention: Keycloak übernimmt die Anmeldung per OpenID Connect, OpenLDAP hält Benutzer und Gruppen, das Portal ist die Startseite. Darunter liegen Dienste wie PostgreSQL, MariaDB, Redis, S3-Objektspeicher und Postfix, die openDesk nur zur Evaluierung mitliefert und die im Produktivbetrieb extern bereitgestellt werden sollen. Jede App bekommt eine eigene Subdomain hinter dem Ingress-Controller; Video, Anrufe und Mail brauchen zusätzlich eigene Ports außerhalb davon.

Wer openDesk betreiben oder auch nur seriös bewerten will, muss wissen, welche Teile voneinander abhängen, wo Daten liegen und welche Netzwerkwege offen sein müssen. Dieser Guide zerlegt das System in Schichten und erklärt jede davon so, dass du danach Installationsanleitungen, Fehlermeldungen und Planungsfragen einordnen kannst.

Prüfstand: Dokumentationsanalyse gegen openDesk 1.19.1 (Repository-Tag vom 6. Oktober 2026), Stand Oktober 2026. Befehle und Konfigurationsbeispiele sind nicht auf einer eigenen openDesk-Installation getestet.

Für wen: Admins, Homelabber mit Kubernetes-Erfahrung und IT-Verantwortliche, die openDesk planen, evaluieren oder einem Team erklären müssen.

Lernziel: Du kannst die Schichten von openDesk benennen, den Weg einer Anmeldung nachzeichnen und für jede Komponente sagen, welche Datenbank, welchen Speicher und welche Netzwerkwege sie braucht.

Voraussetzungen #

• Du weißt grob, was openDesk ist und welche Anwendungen dazugehören (siehe Was ist openDesk?).
• Begriffe wie Pod, Service, Ingress und PersistentVolumeClaim sind dir zumindest dem Namen nach bekannt. Falls nicht, lies vorher oder parallel die Kubernetes-Grundlagen für openDesk.
• Für die lesenden Befehle am Ende brauchst du kubectl-Zugriff auf einen Cluster, in dem openDesk läuft. Zum reinen Verstehen ist das nicht nötig.

Das Gesamtbild in fünf Schichten #

Am einfachsten wird openDesk greifbar, wenn du es von außen nach innen liest: Anfragen aus dem Browser treffen auf den Ingress-Controller, der sie anhand der Subdomain an die richtige App weiterreicht. Die Apps verlassen sich für die Anmeldung auf Nubus. Ihre Daten legen sie in Datenbanken, Caches und Objektspeicher ab. Und alles zusammen läuft als Pods mit Volumes auf Kubernetes.

Das Diagramm ist eine vereinfachte eigene Darstellung. In Wirklichkeit spricht der Ingress jede App direkt an, nicht über Nubus. Nubus liegt im Bild darüber, weil fast jede App beim ersten Aufruf zur Anmeldung dorthin umleitet.

Apps und Dienste: die wichtigste Unterscheidung #

Die openDesk-Doku teilt alle Bestandteile in zwei Typen ein (Tabelle „Applications vs. services“ in docs/architecture.md):

• Applications sind die Werkzeuge für Endnutzer: Nextcloud (Dateien), Collabora Online (Office im Browser), OX App Suite mit Dovecot (Mail, Kalender, Kontakte, Aufgaben), Element mit Synapse (Chat und Anrufe), Jitsi (Videokonferenzen), OpenProject (Projektmanagement), XWiki (Wissen), CryptPad (nur für diagrams.net-Diagramme aus Nextcloud heraus) und Nubus (Portal und Identitätsverwaltung).
• Services sind Infrastruktur: TLS-Zertifikate, ClamAV, der DKIM-Milter, MariaDB, Memcached, PostgreSQL, Redis, Postfix und Objektspeicher.

Der Satz, auf den es ankommt, steht gleich am Anfang der Architekturseite: Datenbanken und Objektspeicher sind nur zur Evaluierung enthalten, im Produktivbetrieb musst du sie selbst bereitstellen. Für den Antivirus-Teil sagt antivirus.yaml.gotmpl dasselbe – produktiv soll ein externer ICAP-Dienst angebunden werden.

Zwei Lücken in der Doku solltest du kennen: Die Service-Tabelle nennt noch MinIO, aber weder SeaweedFS, das seit openDesk 1.15 der Standard-Objektspeicher ist, noch Cassandra, das die Enterprise Edition für Dovecot Pro braucht. Beide gehören inhaltlich ebenfalls zu den Diensten.

Daneben gibt es optionale Apps, die in 1.19.1 standardmäßig aus sind: Notes (kollaborative Notizen, apps.notes.enabled: false) und das neue Whiteboard NeoBoard (apps.neoboard.enabled: false). Notes taucht in der README als Hauptkomponente auf, wird aber ohne eigenes Zutun nicht installiert.

Kubernetes als Plattform #

openDesk setzt einen fertigen Kubernetes-Cluster voraus und richtet ihn nicht selbst ein. Die Anforderungen aus docs/requirements.md in Kurzform:

• Kubernetes ab Version 1.24 aus einer CNCF-zertifizierten Distribution. Getestet wird gegen Cluster, die mit kubespray aufgebaut sind; gegen OpenShift ausdrücklich nicht.
• Für eine erste Evaluierung mindestens 12 CPU-Kerne, 32 GB RAM und etwas über 10 GB Plattenplatz. ARM wird nicht unterstützt, es braucht x86/x64.
• Ein Volume-Provisioner für ReadWriteOnce-Volumes, ein unterstützter Ingress-Controller und für Zertifikate optional cert-manager.

Single-Node-Setups, k3s oder Minikube behandelt die Doku nicht. Aus den dokumentierten Anforderungen lässt sich aber ableiten, dass ein k3s-Cluster mit Standardeinstellungen nicht passt: Der dort übliche local-path-provisioner hat laut Doku keine Sticky-Bit-Unterstützung, und Traefik gehört nicht zu den unterstützten Ingress-Controllern. Das ist ein Schluss aus der Dokumentation, kein Testergebnis. Was das für die Hardwareplanung bedeutet, steht in Systemanforderungen planen.

Helm-Charts und Helmfile: wie die Teile zusammenkommen #

Jede Komponente steckt in einem Helm-Chart, also einem Paket aus Kubernetes-Vorlagen und Standardwerten. Die Doku spricht von über 35 Charts; in helmfile/environments/default/charts.yaml.gotmpl stehen am Tag v1.19.1 51 Chart-Einträge, Enterprise-Varianten eingerechnet. Diese Menge von Hand zu installieren wäre fehleranfällig, deshalb orchestriert Helmfile das Ganze.

Die oberste Datei helmfile-defaults.yaml.gotmpl ruft die App-Helmfiles unter helmfile/apps/ in dieser festen Reihenfolge auf:

1. opendesk-migrations-pre – automatische Migrationen vor allen Komponenten
2. opendesk-services – Zertifikate, Startseiten-Weiterleitung, statische Dateien, optionale Monitoring-Regeln
3. services-external – die gebündelten Dienste wie PostgreSQL, MariaDB, Redis, SeaweedFS, Postfix, ClamAV
4. nubus – Portal und IAM
5. open-xchange – OX App Suite, Dovecot, Postfix-OX, OX Connector
6. nextcloud, collabora, cryptpad, jitsi, element, neoboard, openproject, xwiki, notes
7. opendesk-openproject-bootstrap – verbindet OpenProject mit Nextcloud
8. opendesk-migrations-post – Migrationen nach allen Komponenten

Die Reihenfolge spiegelt die Abhängigkeiten: Erst müssen Datenbanken und Objektspeicher stehen, dann Nubus, weil jede App Keycloak und LDAP braucht, und erst ganz am Ende werden Integrationen wie der OpenProject-Dateispeicher in Nextcloud verdrahtet. Wie Helm und Helmfile im Detail arbeiten und welche Befehle du dafür brauchst, erklärt Helm und Helmfile verstehen.

Nubus: Identität, Portal und Provisioning #

Nubus ist die IAM-Plattform von Univention (IAM steht für Identity and Access Management, also die Verwaltung von Konten, Gruppen und Rechten). In openDesk ist Nubus selbst eine App, besteht aber aus mehreren Bausteinen:

• Keycloak ist der Anmeldedienst (Identity Provider). Er prüft Passwort und gegebenenfalls zweiten Faktor und stellt den Apps Tokens aus. Jede App hat in Keycloak einen eigenen Client.
• OpenLDAP ist das Verzeichnis, in dem Benutzer, Gruppen und Berechtigungen liegen. Keycloak liest diese Daten über LDAP-Federation; mehrere Apps fragen das LDAP zusätzlich direkt ab, jeweils mit einem eigenen Suchkonto.
• Portal ist die Startseite nach dem Login. Es zeigt nur die Apps, für die ein Konto freigeschaltet ist, und bietet Self-Service, etwa das Zurücksetzen des Passworts.
• UMC (Univention Management Console) in einer abgespeckten Fassung ist die Oberfläche, mit der IAM-Admins Konten und Gruppen pflegen.
• Provisioning verteilt Änderungen an Konten an andere Systeme. Die Warteschlange dafür liegt auf einem eigenen Volume (NATS). Aktiv beliefert wird derzeit vor allem die OX App Suite über den OX Connector, der die SOAP-Schnittstelle von OX nutzt. Seit 1.19 koppelt zusätzlich der openDesk Provisioning Connector Matrix-Konten an den Lebenszyklus im IAM.
• Intercom Service vermittelt zwischen Frontends, wenn etwa die Weboberfläche von OX eine API von Nextcloud aufrufen muss (dazu gleich mehr).
• Keycloak Extensions sitzen als Proxy vor Keycloak, bremsen Brute-Force-Versuche und verschicken eine Mail bei Anmeldung von einem neuen Gerät (standardmäßig eingeschaltet, abschaltbar über functional.authentication.newDeviceLoginNotification.enabled).

Für die Rechteverwaltung wichtig: Gruppen aus dem LDAP werden in Nextcloud (zweimal täglich), XWiki (nachts) und OpenProject (stündlich) synchronisiert, aber keine App wertet verschachtelte Gruppen aus. Wer nur Mitglied einer Untergruppe ist, wird ignoriert. Details zur Bedienung stehen in Benutzer und Gruppen verwalten.

So funktioniert Single Sign-on #

openDesk nutzt OpenID Connect (OIDC), eine Anmeldeschicht auf Basis von OAuth 2.0. Die Rollen sind klar verteilt: Keycloak ist der OIDC-Provider, jede App ist ein sogenannter Relying Party, die dem Provider vertraut. Ein Login, zum Beispiel in OpenProject, läuft so ab:

1. Du rufst https://projects.opendesk.example.org auf. OpenProject erkennt keine Sitzung und schickt deinen Browser zu Keycloak unter id.opendesk.example.org.
2. Keycloak fragt Benutzername, Passwort und gegebenenfalls den zweiten Faktor ab und gleicht die Daten mit OpenLDAP ab.
3. Keycloak leitet den Browser mit einem einmaligen Code zurück an OpenProject.
4. OpenProject tauscht diesen Code serverseitig direkt bei Keycloak gegen ein signiertes Token und prüft die Signatur.
5. Du bist angemeldet. Öffnest du danach Nextcloud oder XWiki, besteht bei Keycloak schon eine Sitzung, und die Weiterleitung läuft ohne erneute Passworteingabe durch.

Zwei Sonderfälle gehören ins Bild. Collabora und CryptPad melden sich nicht selbst bei Keycloak an, sondern vertrauen Nextcloud, aus dem heraus sie Dokumente öffnen. Und für Integrationen im Browser gibt es den Silent Login: OX App Suite und Element öffnen im Hintergrund einen unsichtbaren Rahmen zum Intercom Service, der dabei eine eigene Sitzung aufbaut. Über diese Sitzung laufen der Nextcloud-Dateiauswahldialog in OX, die zentrale Navigation und der Newsfeed aus XWiki im Portal. Wie du Zwei-Faktor-Anmeldung, externe Identity Provider oder eine LDAP-Anbindung einrichtest, behandelt Single Sign-on mit Nubus und Keycloak.

Wo die Daten liegen #

Für Backup, Restore und die Frage „Was muss ich extern betreiben?“ ist die Datenhaltung der wichtigste Teil der Architektur. Die Übersicht in docs/data-storage.md und die Standardwerte in database.yaml.gotmpl und cache.yaml.gotmpl ergeben folgendes Bild:

Drei Details sind leicht zu übersehen. Erstens legt OX App Suite zur Laufzeit weitere Datenbanken nach dem Muster PRIMARYDB_n an, die ebenfalls gesichert werden müssen. Zweitens speichert die Enterprise Edition Mails über Dovecot Pro in S3 und Metadaten in Cassandra, die Community Edition dagegen als Maildir auf einem Volume. Drittens ist data-storage.md an einer Stelle veraltet: Synapse-Anhänge stehen dort noch als Volume, seit 1.19 liegen sie standardmäßig im Objektspeicher.

Wer eigene Dienste anbinden will, findet pro Komponente einen Eintrag unter databases.* (zum Beispiel databases.nextcloud mit host, port, name, username, password), unter objectstores.* und unter cache.*. Welche Daten du wie sicherst, behandelt Backup und Disaster Recovery.

Storage: RWO, RWX und das Sticky Bit #

Kubernetes kennt verschiedene Zugriffsarten für Volumes. openDesk unterscheidet zwei davon und lässt sie über eigene StorageClasses steuern (persistence.storageClassNames.RWO und .RWX):

• ReadWriteOnce (RWO) ist Pflicht. Ein solches Volume ist zur selben Zeit nur auf einem Node beschreibbar. Fast alle Volumes von openDesk sind von dieser Art.
• ReadWriteMany (RWX) ist optional. Mehrere Nodes können gleichzeitig schreiben, was manche Komponenten für verteilten Betrieb und horizontale Skalierung nutzen. Eingeschaltet wird das mit cluster.persistence.readWriteMany.enabled: true.

Eine Besonderheit betrifft OpenProject: Kubernetes kann auf normalen emptyDir-Volumes kein Sticky Bit setzen, also die Unix-Berechtigung, die in Verzeichnissen wie /tmp verhindert, dass Nutzer fremde Dateien löschen. Die Temp-Verzeichnisse von OpenProject bekommen in openDesk deshalb Volumes aus der RWO-StorageClass (persistence.storages.openprojectTmp, Standard 5Gi). Der Volume-Provisioner muss das Sticky Bit unterstützen, sonst scheitert der Seeder-Job von OpenProject beim Befüllen der Datenbank. Die Doku nennt ausdrücklich den local-path-provisioner als ungeeignet. NFS ist als Backend für RWO nicht unterstützt, für RWX schon. Getestet wurde laut Doku mit Ceph beziehungsweise cloudspezifischen Speicherlösungen.

Netzwerk: Ingress, Subdomains und Ports #

Eine Subdomain pro App #

openDesk ist ausschließlich für HTTPS über einen voll qualifizierten Domainnamen gedacht. Jede App bekommt eine eigene Subdomain unterhalb der Basisdomain (global.domain). Die wichtigsten Standardnamen aus global.yaml.gotmpl:

Dazu kommen kleinere Namen für Widgets, statische Dateien und die Objektspeicher-Oberflächen. Weil das viele Einträge sind, empfiehlt die Doku einen Wildcard-Eintrag *.opendesk.example.org plus einen Eintrag für die Basisdomain selbst, die auf das Portal weiterleitet. Die Basisdomain sollte wegen eines Fehlers in der Komponente SSSD kürzer als 94 Zeichen bleiben. Die Namen lassen sich über global.hosts ändern, sollten nach dem ersten Deployment aber stabil bleiben, weil manche Links im Portal nicht nachgezogen werden.

Alle diese Subdomains landen beim Ingress-Controller. Ein Ingress ist in Kubernetes ein Regelobjekt, das HTTP- und HTTPS-Anfragen nach Hostname auf interne Services verteilt; ohne laufenden Controller passiert damit nichts (siehe Kubernetes-Doku zu Ingress). openDesk unterstützt zwei Controller:

• haproxy-ingress ist seit openDesk 1.13 dabei und Standard (ingress.controller: "haproxy", ingress.ingressClassName: "haproxy").
• ingress-nginx funktioniert noch, gilt aber als veraltet, weil das Upstream-Projekt eingestellt wurde. Wer ihn nutzt, muss beide Werte auf nginx setzen, sonst passen die erzeugten Ingress-Objekte nicht.

Für die Zukunft plant openDesk laut Doku den Wechsel auf die Gateway API, idealerweise bis Ende 2026. Wie du DNS, Ingress und TLS vorbereitest, steht in DNS, Ingress und TLS vorbereiten.

Ports außerhalb des Ingress #

Nicht alles passt durch einen HTTP-Ingress. Echtzeitmedien und Mail nutzen eigene Protokolle und brauchen direkt erreichbare Ports:

Die SFU (Selective Forwarding Unit, ein Server, der Audio- und Videoströme zwischen Teilnehmern verteilt) ist seit 1.19 neu und hat strenge Anforderungen: Beide Ports müssen unter genau der einen IP erreichbar sein, die die SFU ankündigt. Bei LoadBalancer muss der Anbieter TCP und UDP auf demselben LoadBalancer mit einer einzigen IP unterstützen; reine Hostnamen-LoadBalancer wie AWS ELB funktionieren nicht. Ohne diese Fähigkeit kannst du UDP abschalten (technical.matrix.sfu.rtcMuxedUDP.enabled: false) und nimmst schlechtere Gesprächsqualität bei wackligen Netzen in Kauf. Bei NodePort müssen die Ports im NodePort-Bereich des Clusters liegen. Für Clients, die keinen der Medienports erreichen, sieht openDesk einen externen TURN-Server vor (turn.*).

Wie diese Dienste nach außen gehen, legt cluster.service.type fest: LoadBalancer (Standard, typisch in der Cloud), NodePort (typisch on-premises) oder ClusterIP (abgeschaltet). Für Jitsi, Dovecot, MatrixRTC und Postfix lässt sich der Typ einzeln überschreiben (service.type.*).

TLS-Zertifikate #

Der Ingress-Controller terminiert TLS, also die HTTPS-Verschlüsselung, mit einem Zertifikat aus dem Kubernetes-Secret opendesk-certificates-tls. Für dieses Secret gibt es zwei Wege:

• cert-manager: openDesk legt nur Certificate-Ressourcen an, cert-manager besorgt die Zertifikate, zum Beispiel per Let's Encrypt. cert-manager und seine CRDs müssen vorher installiert sein; der Issuer wird über certificate.issuerRef.name angegeben (Standard: ein ClusterIssuer namens letsencrypt-prod). Mit certificate.wildcard: true lässt sich ein Wildcard-Zertifikat anfordern, das bei Let's Encrypt eine DNS-Validierung (DNS-01) voraussetzt.
• Eigenes Zertifikat: Du legst das Secret selbst in den Namespace und schaltest die Zertifikatsverwaltung mit apps.certificates.enabled: false ab (die Doku zu selbstsignierten Zertifikaten nennt alternativ certificate.create: false; jeder der beiden Schalter wirkt).

Für reine Testumgebungen gibt es zusätzlich Optionen für selbstsignierte Zertifikate und eigene Zertifizierungsstellen (certificate.selfSigned, trust.*). Dann müssen aber auch alle Komponenten der eigenen CA vertrauen, was zusätzliche Konfiguration erfordert.

Mail-Architektur #

Die Mail-Strecke ist bewusst modular, damit Apps auch ohne Groupware Benachrichtigungen verschicken können. Beteiligt sind drei Bausteine:

• Postfix (Basis-Instanz): nimmt Mails der Apps entgegen, die sich mit festen Zugangsdaten anmelden, zum Beispiel Nextcloud, OpenProject, XWiki, Synapse oder Nubus. Sie läuft auch dann, wenn OX App Suite abgeschaltet ist, und stellt außerdem die automatischen Antworten aus Dovecot-Filterregeln zu.
• Postfix-OX: nimmt Mail von außen für die eigenen Maildomains an und dient als Einlieferungsserver für OX App Suite (Anmeldung per OAuth) und für Mailclients (Anmeldung per LDAP). Die Anmeldung prüft Dovecot.
• Dovecot: speichert die Postfächer, stellt sie per IMAP bereit und übernimmt die SASL-Authentifizierung gegen LDAP und OAuth.

Beide Postfix-Instanzen stellen interne Mails per LMTP an Dovecot zu und schicken alles andere direkt an den Empfänger oder an einen konfigurierten Smarthost (smtp.host). Beide hängen am Antivirus-Milter. Ohne OX App Suite entfallen Dovecot und Postfix-OX. Die Doku empfiehlt dringend einen Spam-Milter wie Rspamd (smtp.spamMilter.*), weil sonst externe Absender interne Adressen fälschen könnten. Dovecot läuft laut docs/scaling.md als einzelner Pod und lässt sich nicht horizontal skalieren. Mehr zum Einsatz im Alltag findest du in E-Mail, Kalender und Kontakte.

Abhängigkeiten zwischen den Komponenten #

Aus Architektur und Deploy-Reihenfolge ergibt sich, was woran hängt. Die folgende Liste ist eine Zusammenfassung aus der Doku, kein Ausfalltest:

• Nubus ist der kritische Pfad. Fällt Keycloak aus, kann sich niemand neu anmelden. Fällt OpenLDAP aus, fehlen Keycloak und den Apps die Benutzerdaten.
• PostgreSQL trägt die meisten Apps. Keycloak, Nextcloud, OpenProject, XWiki und Synapse speichern dort ihren Hauptzustand.
• Nextcloud ist Drehscheibe für Dokumente. Collabora und CryptPad öffnen Dateien aus Nextcloud, OpenProject nutzt Nextcloud als Dateispeicher, OX App Suite hängt Dateien aus Nextcloud an.
• OX App Suite liefert die zentralen Kontakte. Nextcloud fragt beim Teilen per Mail das Adressbuch von OX ab.
• XWiki liefert den Newsfeed im Portal, über den Intercom Service.
• Element liefert Videokonferenzen für Termine in OX App Suite; das OX-Backend spricht dafür Element an.

Einzelne Apps lassen sich über apps.<name>.enabled abschalten. Dabei fallen die zugehörigen Integrationen weg. Schaltest du etwa OX App Suite ab, gibt es keine zentralen Kontakte und keine Postfächer mehr, Systemmails verschickt die Basis-Postfix aber weiterhin.

Evaluierung vs. Produktion #

Im Auslieferungszustand bringt openDesk alles mit, was es für einen ersten Test braucht: Datenbanken, Caches, Objektspeicher, Mailserver und Virenscanner laufen als Pods im selben Namespace. Für den Produktivbetrieb ändert sich das Bild deutlich:

• Datenbanken, Caches und Objektspeicher kommen aus eigenen, gesicherten und überwachten Installationen. Die Anforderungen nennt docs/requirements.md (zum Beispiel PostgreSQL 15.x, MariaDB 10.x, Redis 7.x, Memcached 1.6.x). Die gebündelten Varianten schaltest du über apps.postgresql.enabled, apps.mariadb.enabled und Co. ab.
• Antivirus zeigt per antivirus.icap.host auf einen externen ICAP-Dienst.
• Mail hängt an einer vorhandenen Mail-Infrastruktur mit Smarthost, Spamfilter, SPF, DKIM und DMARC.
• Edition: Für den Produktivbetrieb empfiehlt openDesk selbst die Enterprise Edition mit Support und Herstellerpatches. Ein Upgrade von der Community Edition auf die Enterprise Edition wird laut README-EE.md derzeit nicht unterstützt, die Entscheidung gehört also an den Anfang.

Was darüber hinaus für einen belastbaren Betrieb nötig ist – Monitoring, Backups, Updates, Härtung –, sammelt openDesk für den Produktivbetrieb vorbereiten.

Sicherheit #

Ein paar Architekturentscheidungen haben direkte Sicherheitsfolgen:

• Fast alle Geheimnisse hängen an einem Wert. openDesk leitet die meisten internen Passwörter aus der Umgebungsvariable MASTER_PASSWORD ab. Wer diesen Wert kennt, kann sie rekonstruieren. Behandle ihn wie einen Generalschlüssel und lege ihn nie in ein Git-Repository. Ausnahmen laut secrets.yaml.gotmpl sind unter anderem die Schlüssel des Matrix Authentication Service, der Signierschlüssel von Synapse, der selbst mitzubringende Schlüssel für die S3-Verschlüsselung der Synapse-Medien (SSE-C) und das TURN-Secret; sie kommen aus eigenen Umgebungsvariablen oder werden erzeugt und müssen separat gesichert werden.
• Netzwerktrennung ist optional. openDesk liefert Regeln für den Otterize-Operator, der daraus Kubernetes-NetworkPolicies erzeugt. Standardmäßig ist das aus (security.otterizeIntents.enabled: false); ohne NetworkPolicies dürfen sich in Kubernetes alle Pods gegenseitig erreichen.
• Jeder offene Port ist Angriffsfläche. Öffne die Mailclient-Ports nur, wenn du sie wirklich brauchst; sie sind nicht ohne Grund standardmäßig zu.
• Matrix-Föderation mit fremden Servern ist seit 1.18 standardmäßig aus. Die Unterseite matrix-federation.md beschreibt noch den alten Zustand; maßgeblich ist der Standardwert in functional.yaml.gotmpl.

Das vollständige Härtungsthema behandelt openDesk sicher betreiben.

Typische Fehler #

• „openDesk ist eine App, die ich auf einen Server installiere.“ → openDesk ist ein Verbund aus Dutzenden Releases auf Kubernetes. → Plane zuerst den Cluster mit Storage, Ingress und Zertifikaten.
• Gebündelte Datenbanken produktiv nutzen. → Die Doku stuft sie ausdrücklich als Dienste nur für Entwicklung und Evaluierung ein. → Externe Dienste über databases.*, objectstores.* und cache.* anbinden.
• Element-Anrufe ohne Ton oder Bild, Chat geht. → Die SFU-Ports TCP 30000 und UDP 30001 sind nicht erreichbar, oder der LoadBalancer kann kein TCP und UDP auf einer IP. → Firewall und LoadBalancer-Fähigkeiten prüfen, notfalls UDP abschalten oder TURN einrichten.
• Jitsi-Meeting startet, aber Video bleibt schwarz. → UDP 10000 ist nicht offen. → Port freigeben oder TURN nutzen.
• OpenProject-Seeder schlägt fehl. → Der Volume-Provisioner unterstützt kein Sticky Bit, typisch beim local-path-provisioner. → Anderen Provisioner verwenden.
• Nur ingressClassName: "nginx" gesetzt. → ingress.controller steht weiter auf haproxy, die Annotationen passen nicht. → Beide Werte setzen.

Erfolgskontrolle #

Ohne Cluster kannst du dein Verständnis an diesen Fragen prüfen:

• Du kannst erklären, warum PostgreSQL, MariaDB und S3 im Diagramm gelb markiert sind.
• Du weißt, welche Datenbank OX App Suite braucht und welche fast alle anderen Apps nutzen.
• Du kannst den OIDC-Ablauf in fünf Schritten nachzeichnen und sagen, welche Rolle OpenLDAP dabei spielt.
• Du kennst die drei Gruppen von Ports, die am Ingress vorbeigehen.
• Du weißt, welche der beiden Postfix-Instanzen auch ohne Groupware läuft.

In einer laufenden Installation kannst du die Architektur mit lesenden Befehlen sichtbar machen (Namespace hier opendesk):

# Alle Helm-Releases: eines pro Komponente oder Dienst
helm list -n opendesk
 
# Ingress-Objekte mit ihren Hostnamen (eine Subdomain je App)
kubectl get ingress -n opendesk
 
# Services mit externer IP oder NodePort (Jitsi, MatrixRTC, Mail)
kubectl get svc -n opendesk -o wide
 
# Volumes samt StorageClass und Zugriffsart
kubectl get pvc -n opendesk
 
# Stand der automatischen Migrationen
kubectl get configmap migrations-status -n opendesk -o yaml

Die Ausgaben ändern nichts am Cluster. Was die einzelnen Objekttypen bedeuten, erklären die Kubernetes-Grundlagen für openDesk.

Weiterlesen #

• Kubernetes-Grundlagen für openDesk – die Bausteine, auf denen diese Architektur aufsetzt.
• Helm und Helmfile verstehen – wie aus der Architektur ein Deployment wird.
• Systemanforderungen planen – Hardware, Storage und Cluster dimensionieren.
• DNS, Ingress und TLS vorbereiten – Subdomains, Zertifikate und Ports praktisch umsetzen.
• openDesk-Konfigurator – eine erste values.yaml.gotmpl mit dokumentierten Schlüsseln erzeugen.